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and capabilities of 1,000 different computer systems, peripherals, and communications terminals. 
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• EDP Notebook/Europe— A three-volume service for those concerned with computer systems avail¬ 
able in the European marketplace. This Notebook contains the same scope of coverage as the users’ 
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computers, data communications equipment, and peripherals that are sold worldwide. Scope of 
American coverage same as in Users’ Notebook. Updated monthly. 

• Data Communications—A complete reference source on digital data communications equipment and 
techniques. Contains individual, analytical reports on communications terminals and processing 
equipment, detailed reports on common-carrier facilities, and a guide to the design of effective data 
communications systems. Updated monthly. 

• Time Sharing—A two-volume service covering all aspects of commercial time sharing. It includes 
reports on the state of the time sharing art, time sharing languages, applications, equipment and 
individual reports on commercial time sharing services. Updated bi-monthly. 

• Software Reports—A service on proprietary software packages presenting detailed information on 
the operation and implementation of specific software packages as well as in-depth definitional re¬ 
ports on computer applications. Comparison charts assist the user in the selection of packages. Up¬ 
dated monthly. 

• Minicomputer Reports— Covers small business computers, minicomputers, and intelligent terminals. 
The information is presented in detailed reports and easy-to-use comparison charts. Current pric¬ 
ing for each device is also listed. An abridged Notebook service is also available for both the 
Domestic and International markets. Updated monthly. 

• Input/Output Reports— In 3 volumes, the Reports cover a wide range of computer support equip¬ 
ment, storage and retrieval systems, microform readers/printers, plotters, industrial and retail data 
collection, and phototypesetters. The information is presented in analytical reports on individual 
products as well as easy-to-use comparison and pricing charts. Updated monthly. 

• Microform— Single-volume coverage of COM, CIM, readers/printers, retrieval systems, microform 
camera, processors, and duplicators. Same detailed reports and chart data as Volume 3 of Input/ 
Output Reports. Updated monthly. 

• Desk Reference Series— Computer Characteristics Digest and Minicomputer Characteristics Digest. 
Each is a concise compilation of comparison charts and price data from the corresponding looseleaf 
Computer Technology Reports. The Digests meet the need for convenient, single-volume references 
that are used as quick sources of the products and services available. They are completely revised 
and reissued every 6 months. 

• Data Processing Manual —A new service that helps you solve daily problems in general manage¬ 
ment, DP administration, system development, standards, practices, and documentation, operations, 
and technology. A practical and handy set that is constantly useful. In portfolio format, issued 
monthly. 
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PREFACE 


The AUERBACH Guide to Operating Systems 
presents a description and evaluation of the major 
operating systems and their independently vended 
enhancements now used extensively throughout 
the data processing industry. The Guide is a 
working document designed to: (1) provide a sim¬ 
ple to understand tutorial on the philosophies and 
principles of contemporary operating systems; 

(2) provide data processing managers with facts 
about their operating system that will allow them 
to increase both job throughput and resource uti¬ 
lization; and (3) provide guidelines that will allow 
system planners to select the operating system 
that best fits present and projected needs. 

The entire Guide is built around a Product 
Class Report which describes and evaluates the 
principal functions of an operating system, in¬ 
cluding job scheduling, resource allocation, pro¬ 
gram control, processing support, data manage¬ 
ment, and so forth. Since the topics covered in 
that report form the basis for our evaluation of 
the specific operating systems, it’s important 
that you read it first. Otherwise the value of the 
information — particularly that covered under 
FUNCTIONAL CHARACTERISTICS — will be 
diluted. 

Our evaluation of each operating system’s ef¬ 
ficiency was based on its ability to schedule jobs, 
allocate resources, and handle general job 
throughput in a volatile, large volume job mix 
environment. We chose this environment because 
we firmly believe that computers must be cost- 
effective. In most cases, that goal can’t be 
reached unless the machine is running at full ca¬ 
pacity, processing a realistic job mix (not all 


high priority jobs) and fully utilizing all its 
resources. 

Most operating systems, as you will see, can’t 
stand up to this ’’worst-case” situation partially 
due to philosophical and design limitations and 
partially due to misuse on the part of the user. 
The latter problem in a majority of cases can 
also be traced to design features that permit un¬ 
necessary liberties with the system. 

By pointing out design flaws, we’re not trying 
to knock the vendor; he’s only giving the public 
what he believes they want. What we’re attempt¬ 
ing to do is nudge the vendor into taking affirma¬ 
tive action that will benefit all parties and point 
out to users those areas that might pose problems. 

AUERBACH Guide to Operating Systems is an 
expansion of material derived from AUERBACH 
Software Reports. This service is a major unit 
in the AUERBACH Computer Technology Reports, 
a looseleaf service recognized as the standard 
guide to EDP throughout the world. They are pre¬ 
pared and edited by the Publisher’s staff of pro¬ 
fessional EDP specialists. 

Material in this volume has been updated prior 
to publication; however, the field is changing so 
rapidly that the Publishers cannot guarantee the 
completeness of its contents. For current infor¬ 
mation on data communications and significant 
companies offering products in this field, please 
refer to AUERBACH Software Reports. Informa¬ 
tion can be obtained from the Publisher, 
AUERBACH Publishers Inc., 121 North Broad 
Street, Philadelphia, Pa. 19107. Telephone 
(215) 491-8400. 
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PRODUCT CLASS REPORT 

Operating Systems 


OVERVIEW 

An operating system is a comprehensive group 
of routines that contributes to the efficient and 
convenient running of programs on a computer. 

It does so by assigning many housekeeping tasks 
to the computer, thus removing them from the 
manual control of the operator. With operating 
systems, computers can perform instructions at 
speeds that are orders of magnitude faster than 
a human being can react. 

Because of the complexity and variety of tasks 
it is required to perform, however, the coding 
for an extensive operating system can occupy a 
significant portion of the computer’s memory. 
Consequently, the development and growth of op¬ 
erating system technology relates closely to im¬ 
provements in both computer memory and soft¬ 
ware technology. 

The software constituting an operating system 
consists of a monitor routine and a number of 
special-purpose housekeeping routines automati¬ 
cally controlled by the monitor. The monitor 
routine is known by many names, depending on 
the manufacturer or vendor. For this report, 
however, the term executive will be used. 

The actual facilities called operating systems 
vary widely. Some, designed to run on a mini¬ 
mum configuration system, provide only the bare 
essentials for controlling the operation of a com¬ 
puter; the user must code and insert any addi¬ 
tional facilities. Others provide virtually com¬ 
plete control over the operating functions. An 
operator communicates with these operating sys¬ 
tems normally through job control statements 
entered via a dedicated system device, such as 
a card reader, or perhaps through the console 
keyboard. In using a comprehensively designed 
operating system, the operator communicates 
only a small amount of control information, 
which then regulates all other aspects of the com¬ 
puter’s operation. 

In addition to supervising the running of a 
single program on a single computer, some op¬ 
erating systems can simultaneously regulate a 
number of computers (multiprocessing) and/or 
direct the simultaneous execution of a number of 
programs on a single processor (multiprogram¬ 
ming). To facilitate multioperation and enhance 
a computer’s capability during individual runs, 
an operating system can also control the loading 
of programs into core from auxiliary storage 
devices and the allocation of such computer facil¬ 
ities as storage and I/O units. 

Additional facilities intended to minimize op¬ 
erator intervention include controls for error 


handling, diagnostics, and automatic restarting 
of a program, as well as special routines to as¬ 
sist in the running of an installation. Examples 
of these special routines include overflow con¬ 
trol, I/O blocking and deblocking (in which com¬ 
puter words are combined into physical units of 
data or vice versa), control of messages, and 
general or special provisions for producing a 
dump of the contents of selected core locations 
and registers. 

Program loading is facilitated by routines 
that place a previously generated machine lan¬ 
guage program into memory or by a load-and- 
go procedure that converts the source coding di¬ 
rectly into machine language. Load-and-go ca¬ 
pability increases computer throughput because 
the source program can be loaded and executed 
as one continuous job — no breaks. Loader pro¬ 
grams include a feature called linking, which 
establishes connections between executable pro¬ 
grams and any subroutines with which they need 
to communicate. 

Most multiprogramming and multiprocessing 
operations are implemented through program 
overlays, although overlapping is also used in 
some cases. The overlay technique is used when 
the total storage required for instructions and 
data exceeds the available main storage. It al¬ 
lows several program modules to be placed in 
the same storage area at different times by 
bringing routines into core storage from auxiliary 
devices. Overlapping means transferring data to 
or from 1 portion of core storage while instruc¬ 
tion execution continues in other portions; it can 
be implemented if the hardware configuration in- 
includes independently controllable I/O mem¬ 
ory processors. 

The main thrust of this report concentrates 
on describing and analyzing the executive and 
supervisory software, which collectively is 
called the operating system. It is intended as a 
guide to selecting the best operating system to 
meet an organization’s present and projected 
processing needs. To that end, considerable ef¬ 
fort has been expended to analyze those functions 
which affect the ability of the system to perform 
its major functions, viz. , (1) to minimize the 
programmer’s concern with system environment 
(i.e., computer operation, job scheduling, I/O 
operations, external and internal storage alloca¬ 
tion) and (2) to maximize the overall effectiveness 
of the computer system. 

System Types 

There are 4 basic types of operating systems: 
serial batch, multiprogramming, time sharing, 
and real-time. Serial batch employs sequential 
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job scheduling; that is, jobs may come in via card 
reader and be executed immediately, or they may 
be stored on a fast direct access device (usually 
adisc)and executed asthe system can handle them. 
In serial batch mode, jobs run one at a time. 

A multiprogramming system allows a number 
of jobs to run concurrently. This does not mean 
the simultaneous operation of 2 (or more) jobs; 
rather it is an interleaved operation. Simply 
stated, with interleaving, portions of one job are 
processed during the interim when another pro¬ 
cessing job has been temporarily interrupted 
(generally to service an I/O request). Such pro¬ 
cessing is possible due to the fast internal speeds 
of the third-gene ration machines, plus the dis¬ 
parity in the speeds of I/O and CPU equipment. 
I/O devices operate in the millisecond range; 

CPU operations, on the other hand, are per¬ 
formed in nanoseconds. Thus while one job is in¬ 
terrupted for an I/O, the CPU is free to process 
many operations of other jobs. 

A time sharing system allows many users to 
treat the computer as though each had exclusive 
use of it. Each job receives CPU control for a 
defined amount of time called a time slice. At 
the conclusion of its time slice, a job is inter¬ 
rupted and the CPU is given to the next waiting 
job. This process continues until all jobs have 
been serviced and until all jobs terminate. 

Users generally communicate with the system 
via a low-speed terminal such as a teletypewrit- 
er-like device or a video display unit with a key¬ 
board. The illusion of exclusivity, even when a 
high number of operations is involved, is the re¬ 
sult of the disparity between the speeds of I/O 
and CPU operation, thus freeing the computer to 
service other users. 

The real-time system appears to be much like 
time sharing in that remote slow-speed terminals 
are used to communicate with the system. How¬ 
ever, the real-time system does not process jobs 
simultaneously; nor is it used when a large num¬ 
ber of computations is involved. Users enter 
only data — as opposed to programs — from ter¬ 
minals. Real-time systems are geared for large 
amounts of I/O activity, usually involved in up¬ 
dating data bases and/or initiating process con¬ 
trol operations (e.g., adjusting valves). 

OPERATING SYSTEM COMPONENTS 

All third-generation operating systems con¬ 
tain components that handle job management, 
system resource management, system manage¬ 
ment, and data management functions. 


The job management functions are handled by 
a group of routines collectively called the execu¬ 
tive (or in some systems, the supervisor). Ba¬ 
sically, the executive is responsible for organiz¬ 
ing and regulating the flow of work in a computer 
system by initiating and controlling the execution 
of tasks. It also allows users to communicate 
with the system either through operator com¬ 
mands or control cards. 

In most systems, system resource manage¬ 
ment works in conjunction with the executive and 
for this report will be considered a subset of it. 
Resource management is concerned with allocat¬ 
ing system resources to the program previously 
selected for execution. These resources typi¬ 
cally include main storage, CPU time, I/O op¬ 
erations, and system timing services. 

System management is concerned with system 
generation (i.e., tailoring and adapting a gen¬ 
eralized system to the specific median configura¬ 
tion and operational requirements of an installa¬ 
tion), system maintenance, program maintenance, 
and compiler interfaces. 

System maintenance allows an installation to 
update the operating system in response to 
changes in the operating environment, or to 
changes to the operating system programs them¬ 
selves. Depending on the nature of the changes, 
some can be accomplished dynamically by the 
system, while others require suspension of all 
processing until the update has been completed. 

Data management functions consist of file 
management facilities, I/O support facilities, 
and data management system facilities. File 
management facilities provide file support for 
the system files as entities rather than for the 
individual data records within the files. Support 
for the latter is provided by the other two data 
management categories. 

I/O support facilities enable a program to ac¬ 
cess and process individual data records within 
the file. These facilities are normally invoked 
by using macroinstructions within the processing 
program and eliminate the need for program¬ 
mers to be concerned with many of the problems 
of reading and writing data records. 

Data management systems allow a user with 
limited programming interests to perform such 
functions as retrieving and displaying selected 
portions of the file. Generally, data manage¬ 
ment systems are adjuncts to an operating sys¬ 
tem and are more or less self-contained, depend¬ 
ing on the architecture of the particular system. 
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Consequently, a data management system makes 
use of many of the features provided by other op¬ 
erating system functions in its own internal 
design. 

Of the components comprising an operating 
system, those dealing with job and system re¬ 
source management are considered the most im¬ 
portant, for they ultimately reflect the efficiency 
and ease of use of the system. Therefore, the 
greatest portion of this report deals with their 
operations. 

Job Control Language 

The job control language of an operating sys¬ 
tem is important because to a large extent it re¬ 
flects the ease of extensibility and the ease of use 
of a system. Languages can be verb oriented, 
that is, can have a large number of statements 
each of which contains a small number of param¬ 
eters (e.g., Burroughs MCP Program Control 
Cards); or they can be parameter oriented, that 
is, can have a small number of statements in 
which a large number of parameters are grouped 
(e.g., IBM T s OS Job Control Language). For a 
high-function system, a control language that is 
verb oriented is generally easier to write and 
easier to read (self-documenting); it is also more 
flexible with regard to reflecting system exten¬ 
sions, since it is able to encompass new state¬ 
ments as well as parameters. 

Parameters fall into two groups, positional 
and keyword. A typical statement with positional 
parameters is: RUN program-name compiler- 
options . A typical statement with keyword param¬ 
eters is: RUN PROG=program-name, OPTIONS= 
compiler-options. The easiest to read and to 
learn are the reserved word positionals for a 
statement-oriented language and the keywords 
for a parameter-oriented language, since these 
are generally free-form to the extent that their 
order is not preordained. However, extension 
of a parameter-oriented language is cumber¬ 
some at best; appropriate reflection of system 
enhancements in the control language is invari¬ 
ably a problem. 

EXECUTIVE FUNCTION 

The executive function of an operating system 
principally involves job management — the initia¬ 
tion, scheduling, monitoring, and control of jobs. 
In processing a job, the executive is actually 
concerned with handling independent job elements 
called tasks, which are the basic work units. 

Four elements — or subfunctions — comprise 
the executive: job control, I/O control, system 


communication and recovery processing. Job 
control consists of those functions that regulate 
the use of system resources by the various tasks 
comprising each job step. Specifically, job con¬ 
trol handles job scheduling, resource allocation, 
program loading, and program termination. 

I/O control refers to system control over the 
activities of the I/O devices. This includes 
scheduling, data transfer, and remote terminal 
support. 

System communication encompasses the func¬ 
tions involved in the exchange of information be¬ 
tween user and operating system. This communi¬ 
cation can range from controlling the execution of 
scheduled jobs to configuring system components 
and monitoring system status. Examples of sys¬ 
tem communications are system startup, job con¬ 
trol communication, I/O stream control, re¬ 
source status modification, and system status 
interrogation. 

Recovery processing routines are invoked 
whenever an external error will prevent a partic¬ 
ular job from continuing normal processing. 

These routines attempt to avoid abnormal job 
termination by restarting the execution job from 
a predetermined point in the processing cycle. 
Such a capability is called checkpointing and 
restarting. 

Scheduling 

Scheduling consists of selecting a job that is 
available for processing and preparing it for exe¬ 
cution. The job selection process can be very 
simple or extremely complex, depending on the 
mode of system operation (i.e., batch, real¬ 
time, or time sharing). 

Real-time processing uses the most straight¬ 
forward method, whereby priorities are assigned 
to each type of task. A higher-priority task is 
always scheduled for processing ahead of a lower 
priority task and, when necessary, will suspend 
the lower-priority processing to attain the re¬ 
sources it needs. Sophisticated systems schedule 
jobs based on clock time; that is, a job is initi¬ 
ated at a certain time or is initiated to be com¬ 
pleted at a certain time. 

Time sharing also uses a relatively straight¬ 
forward technique. Here, the user requests ac¬ 
cess from his console and the scheduler deter¬ 
mines if he can proceed. If so, he may start pro¬ 
cessing immediately and jobs are serviced on a 
time-sliced basis. If not, he must reinitiate his 
request. Generally, a processing request is de¬ 
nied if no communication line is free. Required 
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resources may be defined either in a user pro¬ 
file maintained by the system or during the log¬ 
on processing procedure. 

The greatest variation in scheduling techniques 
exists in the handling of batch processing. Most 
operating systems permit scheduling via one or a 
combination of the following techniques: sequen¬ 
tially, by numeric priority classification, by job 
class priority, by job class numeric priority, by 
start time limit priority, by passover limit pri¬ 
ority, or by projected resource utilization 
priority. 

Sequential Scheduling . The simplest is the 
sequential technique; here each job is scheduled 
for execution according to its sequence in the in¬ 
put stream. The first job entered is the first one 
processed; no priorities can be assigned to jobs. 
This technique is commonly used with a non- 
spooled I/O environment and can significantly re¬ 
duce throughput especially when a number of 
large jobs are being processed or are awaiting 
processing. 

An input technique allowing greater job sched¬ 
uling sophistication involves reading the entire 
input stream and storing the card images on a 
high-speed secondary device such as a disc. 

Two benefits are derived from this: First, jobs 
can be executed in an order other than the input 
sequence; second, scheduling parameters can be 
used to control the execution sequence. The 
more commonly used scheduling parameters are: 
numeric designator, job class, job class numeric, 
stait time limit, and passover limit. 

Numeric and Job Class Priority Scheduling . 
The numeric and job class priority schemes are 
conceptually and operationally quite similar. 

With the numeric priority scheduling scheme, the 
user is restricted to employing a predefined 
group of numerals to indicate which jobs should 
be considered for processing before other jobs. 
The highest-priority jobs are assigned the high¬ 
est priority number. All jobs with the same nu¬ 
meric designator are stacked in queues reserved 
for that class. 

Generally, the numeric priority technique 
schedules all higher-priority jobs before consid¬ 
ering any with a lower priority. This unfortu¬ 
nately can lead to serious throughput degradation 
particularly when a large number of high-priority 
jobs is being processed. With the numeric 
scheme, consequently, considerable control must 
be exercised by the user to ensure that an accept¬ 
able job mix is maintained. 

The job class priority scheme substitutes a 
job class designator for the numeric designator; 


other than that, it works the same way and has 
the same problems as the numeric priority tech¬ 
nique. Generally the job class priority scheme 
is employed with fixed memory partitions as op¬ 
posed to variable size memory regions. 

Job Class Numeric Scheduling . Jobs in the 
numeric and job class categories are usually 
stacked in their respective queues and serviced 
on a first-in, first-out (FIFO) basis. This form 
of selection can also lead to problems, however, 
since the user has no control over which job in 
each queue should be selected ahead of another 
job. This problem is solved via the job class 
numeric priority scheduling technique. Basi¬ 
cally, this method employs double weighting, 
where the user assigns a priority designator to 
the job class itself and another value to each job 
within the class. In scheduling, the system ser¬ 
vices the highest-priority job class first; but in¬ 
stead of selecting the first job in the queue, it 
scans the entire queue and schedules those jobs 
with the higher numeric designation. In case of 
numeric contention, jobs with the same prior¬ 
ity designator are serviced FIFO. 

Start Time Limit Scheduling . Although the job 
class numeric technique provides more control 
over which jobs are selected ahead of others, it 
still does not guarantee increased throughput 
since relatively low-priority but time-dependent 
jobs may still remain ’’buried’’ in their queues. 
This problem can be greatly reduced (if not to¬ 
tally eliminated) by assigning start time limits to 
jobs. 

The start time limit allows users to indicate 
when a job should be considered for execution, 
and to specify the time of day or time elapsed 
from submission by which the job must be com¬ 
pleted. If the deadline cannot be met under nor¬ 
mal scheduling, the system assigns the job the 
highest priority in the mix as the deadline ap¬ 
proaches. Another form of deadline lets the user 
specify the elapsed time or time of day when a 
job should finish. If the job is processing and it’s 
evident it won’t finish on time, the system re¬ 
quests some form of operator action (e.g., can¬ 
cel the job, change its priority). 

Passover Limit Scheduling . The passover 
limit scheduling technique permits the user to 
indicate the number of times a job can be passed 
over before it must be scheduled. When this 
limit is reached, the job’s priority is upgraded 
to the highest in the mix. 

Projected Resource Utilization Priority . The 
projected resource utilization priority technique 
requires that the programmer submit estimates 
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of the total resources to be utilized by the pro¬ 
gram, e.g., CPU time, number of output lines 
(printer), number of cards punched (punch). Jobs 
are then assigned priorities on the basis of total 
use, as determined by the system’s algorithm, 
with the jobs of least utilization being assigned 
the highest priorities. To preclude an errant pro¬ 
grammer from lowering his estimates to effect 
higher priority, the estimates of the total re¬ 
sources to be used generally are also construed 
by the system as maximums. Therefore, a large 
Cobol compilation-execution, involving sorts, 
which may take 20 minutes of CPU time, could 
easily be canceled if the programmer errs so 
much as 100 lines in his estimate of printed 
output. 

This scheduling technique maximizes through¬ 
put for small jobs but can be disastrous for large 
jobs. There is usually a clock cycle that auto¬ 
matically increments the priority of a job for ev¬ 
ery hour that it remains on the queue; the maxi¬ 
mum wait for turnaround in the cases of large 
jobs generally doesn’t exceed 12 hours. 

These 7 commonly used scheduling techniques 
share 2 common weaknesses: They do not guar¬ 
antee that the processing job mix will efficiently 
utilize the system resources, and no safeguards 
are provided to prevent a marginally efficient 
high-priority job awaiting execution from ’’rolling 
out” or canceling a number of efficiently executing 
lower-priority jobs in order to gain access. The 
latter weakness can result in significantly re¬ 
duced throughput. 

A technique that, conceptually, could solve 
both problems would employ atri-priority scheme. 
The three factors affecting scheduling are job 
mix, process, and schedule priority designator. 
The schedule priority uses a technique similar to 
the ordinary numeric priority scheduling methods 
to aid in selecting jobs for the system mix. The 
process priority considers whether the job will 
maximize total throughput by optimally utilizing 
the available system resources. The job mix 
priority determines which program can be sus¬ 
pended to make room for higher-priority pro¬ 
grams and still maintain a high level of throughput. 

Resource Allocation 

The allocation of system resources (i.e. , 
main storage, I/O devices, CPU time, and in¬ 
formation files) is handled by routines that read 
job requirements and assign resources in a way 
that (hopefully) avoids conflicting assignments. 
Users specify the needed resources in the JCL 
parameters, or they are contained in generated 
data blocks produced by the program binding 
process. 


With serial processing, the resource alloca¬ 
tion routines are rather simple since all re¬ 
sources are normally made available to the pro¬ 
cessing program. Multiprogramming and time 
sharing environments, however, require more 
sophisticated routines in order to avoid conflicts 
particularly when common resources are being 
used. Because of this, many scheduling algo¬ 
rithms require that all needed resources be stat¬ 
ically assigned prior to initiating the job. 

There is a tradeoff, however, in using the 
static assignment technique. The advantage of 
having all resources available guarantees that the 
job can run to completion with no delays to await 
the ’’freeing up” of needed resources. However, 
once resources have been assigned they may be 
retained unnecessarily throughout the entire job 
run. Consequently, other jobs, which could start 
if unneeded resources were released, must wait 
until the job terminates. 

Some systems permit a job to start with only 
minimal resources available. This technique 
gains little if the system has no provision for 
’’looking ahead” to ensure that resources will be 
available when needed. In this case, re source- 
shy processing jobs must be suspended and placed 
in a wait queue until their required resources be¬ 
come available. 

The inconvenience of delayed processing is 
not the only problem incurred with this tech¬ 
nique. If jobs are permitted to retain their re¬ 
sources throughout the run, a suspended job 
could deprive another of a needed resource, thus 
preventing it from either starting or continuing 
processing. If enough jobs enter the suspended 
state, overall throughput is significantly reduced. 

Many of the aforementioned problems are al¬ 
leviated through a technique called dynamic re¬ 
source allocation. This method also takes note 
of the total resources required but permits an 
executing program to request the use of a re¬ 
source only when it’s needed. The system hon¬ 
ors such requests by removing the resource 
from a common pool; when the resource is no 
longer needed, it is returned to the pool. 

Dynamic resource assignment is usually found 
only in extended multiprogramming systems and 
is primarily advantageous where a large number 
of programs are executing concurrently. Since 
resources are only committed when they are 
being used rather than for the duration of an en¬ 
tire job, the technique may significantly reduce 
the total number of resources required for oper¬ 
ating efficiency when compared with an environ¬ 
ment using static allocation. The price for dy¬ 
namic allocation is higher operating system 
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overhead, and an increased possibility of re¬ 
source "deadlocking" occurring. 

As mentioned, system resources consist of 
main storage, I/O devices, CPU time, and in¬ 
formation files. The following is a brief discus¬ 
sion of how each is assigned. 

Main Storage . There are 5 basic methods 
for allocating main storage in a multiprogram¬ 
ming environment. The first involves the static 
assignment of fixed foreground and background 
processing areas. Foreground processing areas 
are generally allocated to real-time or time 
sharing processing, while the background area 
is generally allocated to batch processing. This 
form of storage organization is characterized by 
the fact that program priority is determined by 
the storage assignment; i.e., foreground areas 
always have execution priority over background 
areas. 

The second method involves a series of fixed 
independent partitions of varying sizes. Each 
partition may have a separate input stream, or 
programs may be assigned to the smallest avail¬ 
able partition that will hold them. In the latter 
case, the system may also provide parameters 
that prevent some programs from being assigned 
to certain partitions. 

The third method involves maintaining all free 
internal storage as a large pool of storage. Each 
program is assigned the exact amount of contig¬ 
uous storage it requires, and upon terminating 
the used storage is returned to the pool. If time 
sharing operations are undertaken in this environ¬ 
ment, a block of storage is normally removed 
from the pool to handle all of the time-shared 
applications. 

With the fourth method, main storage is seg¬ 
mented into a series of fixed pages of relatively 
small size, which are also maintained in a pool. 
Program instructions and data are likewise seg¬ 
mented into pages. 

When storage is divided into pages, program 
loading may consist of loading all of the required 
main storage pages, or it may involve preparing 
the system for a process called paging. Paging 
requires a fast access secondary storage device 
(usually a disc or drum) as a supplement to main 
storage. Both the secondary storage device and 
main storage are configured to the same fixed 
page size. 

The complete program resides on the secon¬ 
dary storage device; the page containing the in¬ 
struction sequence currently executing is in main 
storage. Whenever another page is referenced. 


a page area is made ready in main storage — 
perhaps by moving a resident page to secondary 
storage — and the required page is read in. 

A page map is maintained, indicating the phys¬ 
ical page assignments (main storage or secon¬ 
dary storage) and the actual storage address 
(core locations or track). This map is consulted 
to resolve addresses when accessing the data or 
instructions within the page. In many systems 
this address resolution is accomplished through 
hardware circuitry. In others, it must be ac¬ 
complished by means of software. 

Implementation of the paging concept provides 
for programs of seemingly unlimited size, since 
a program need no longer be restricted by the ac¬ 
tual main storage memory of the computer. On 
the other hand, paging involves considerable 
overhead in shuffling pages between main and 
secondary storage so that the increased capability 
is not without cost. When the system is heavily 
involved in shuffling pages, it can do little or no 
productive work. Such a condition is called 
"thrashing. " 

Several interesting methods have been de¬ 
veloped to minimize the amount of page transfer 
between secondary and main storage and thus re¬ 
duce the chances of CPU thrashing. A common 
technique is to attempt to determine the page 
least likely to be referenced in the future and re¬ 
move it from main storage whenever a new page 
area is required. Another is to remove only 
pages that have not been modified since they have 
been read in. The latter method avoids the re¬ 
quirement for writing the page contents onto sec¬ 
ondary storage since the previous version of the 
page on secondary storage can still be used. 

Once the main storage has been allocated, the 
program usually requires additional storage for 
buffers, program expansion, and so forth. Most 
systems assign this dynamically, extracting the 
required storage from common pools which are 
independent of normal allocatable storage. When 
this temporary storage is no longer needed, it 
is returned to the pool either explicitly by the 
program or implicitly when the program 
terminates. 

Paging offers an additional benefit in that it 
almost eliminates a phenomenon called "checker¬ 
boarding. " Checkerboarding — sometimes called 
memory fragmentation — occurs when a contigu¬ 
ous region of main storage is available in a non- 
fixed partition environment but either can’t be 
used or is not currently being used. In either 
case, a valuable system resource is wasted. The 
reasons for checkerboarding can be traced to poor 
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job scheduling on the part of the user or the lack 
of a memory compression feature on the system — 
or both. 

For example, take the case of a system with 
100K bytes of main storage currently processing 
three programs requiring 20K bytes, 60K bytes, 
and 20K bytes, respectively, and in that order top 
to bottom. Assume that the 20K-byte jobs are fast 
turnaround types, while the 60K-byte job is com¬ 
pute bound. When the two 20K jobs terminate, 
this collectively leaves 40K bytes available for 
the next job. If memory compression can be per¬ 
formed, the system shifts the 60K job so that 20K 
bytes of it moves into the vacated 20K-byte area. 
This results in the creation of a contiguous 40K 
area for the next job. 

If compression is not permitted, a 20K-byte 
area is left on either side of the 60K job. Of 
course, if the jobs in the waiting queue can fill 
these holes, the resource is not wasted. When 
the waiting jobs singularly exceed 20K, however, 
they are not scheduled because a contiguous 
amount of storage is unavailable. Thus checker¬ 
boarding occurs. 

Even with compression, checkerboarding can 
result due to poor job scheduling by the user. 

The most obvious example is scheduling a job or 
jobs that will not fill the vacated area. A not-so- 
evident example occurs when programs employ¬ 
ing nonfixed segmented overlays are used. This 
form of construction employs a root segment, 
which is always main storage resident during a 
run, and overlays of varying sizes. Usually, the 
programmer writes the segments and is required 
by the system to reserve enough main storage to 
hold the largest overlay. If this area is reserved 
for the entire run, a checkerboard occurs when 
the smaller segments are running. 

Admittedly, it’s almost impossible to prevent 
checkerboarding in this environment — even with 
the most clever programmers. However, if the 
system were to expand and compress main stor¬ 
age as needed, the problem would be solved. 

This form of compression, unfortunately, is used 
by few systems. 

Virtual memory (or virtual storage) is the 
fifth method for allocating main storage. Essen¬ 
tially, virtual memory amounts to using high¬ 
speed discs and drums to provide inexpensive (but 
slower) expansions to main storage. Thus, main 
storage appears to be larger than it actually is. 

Operating systems for virtual memory assume 
additional responsibilities, the most important of 
which is management of the real memory re¬ 


source. This is called mapping, the procedure 
of maintaining a one-to-one correspondence list 
of virtual memory addresses on backing store 
versus real main storage locations. 

Virtual memory can be paged or segmented. 
Paged memory has one very big advantage: pro¬ 
grammers need no longer be concerned about pro¬ 
gram size. For all practical purposes, partitions 
in virtual store can be as large as needed. Thus, 
applications programmers can focus their efforts 
on the application; those concerned with program 
maintenance don’t have to worry about fitting an 
altered program into a partition (they just en¬ 
large the partition and, if necessary, move others 
around); and system programmers no longer have 
to modularize a program and provide linkages 
between modules and can now concentrate on job 
priority management. 

The chief drawback of paged virtual memory 
is that a system could require page swaps be¬ 
tween memory and virtual store at such a rate 
that the system is overwhelmingly preoccupied 
with paging, thus resulting in thrashing. 

Segmented virtual memory uses variable seg¬ 
ments of main and virtual memory space based 
upon logical division points of programs. At its 
present developmental level it has some severe 
drawbacks: The segment space in real memory 
must be contiguous and must be allocated to be at 
least as large as the largest program segment. Un¬ 
less all logical program segments are nearly the 
same size, small segments will waste precious 
real memory. Hence, the programmer must en¬ 
deavor to create programs of nearly equal length 
blocks. Segmented virtual memory will work 
nicely with specially designed compilers, though, 
and is hardly ever subject to thrashing because 
segments tend to be larger than pages. 

It should be pointed out that theoretically any 
system could implement virtual memory in soft¬ 
ware. All that needs to be done is to apply traps 
for addresses and create a reference table and 
mapping program. When important functional 
aspects of such a system are hardware imple¬ 
mented, a manufacturer can more validly claim 
to have developed a virtual memory system. 

Users shouldn’t allow themselves to be ’’wowed” 
by buzzwords like virtual memory. They should 
also remember that the direct access backing 
store for virtual store implementation is 3 to 5 
orders of magnitude slower than a computer’s 
main store. 

Another point should be made clear to users 
of virtual memory systems, namely, the execu¬ 
tion time for a specified job in a virtual system 
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is likely to be longer than in a nonvirtual system. 
The advantage presented by the virtual system is 
in multiprogramming efficiency, for total system 
throughput. 

I/O Devices. The techniques used to assign 
I/O devices vary with the processing environ¬ 
ment. In the background/foreground mode, for 
example, I/O device configurations are usually 
assigned permanently to one of the background 
or foreground partitions. Consequently, any al¬ 
teration to a configuration must be done by the 
operator. Real-time systems, on the other hand, 
do not control I/O assignments at all. Thus, pro¬ 
gramming conventions must be used to avoid de¬ 
vice utilization conflicts. 

With partitioned and paged environments, I/O 
devices may be allocated statically or dynami¬ 
cally. Generally, systems oriented towards unit 
record or serial devices use static assignments. 
Those oriented towards the use of random access 
and teleprocessing devices usually employ dy¬ 
namic assignments. 

CPU Time. The assignment of CPU time to 
jobs in a multiprogramming or time sharing en¬ 
vironment is controlled by the operating sys¬ 
tem’s dispatcher routine. The dispatcher is re¬ 
sponsible for selecting a waiting job and assign¬ 
ing the processor to it. 

Normally, candidates for processing in a 
batch environment are entered into a dispatching 
queue, the highest-priority job being the first 
entry. If the system design calls for all re¬ 
sources to be available before processing begins, 
they must be assigned before entering this queue. 

The dispatcher selects the first job, assigns 
the processor to it, and permits it to run until 
a request for service is made. That job is then 
returned to a queue (generally called a wait 
queue) and the next highest job is selected for 
processing. When the request issued by the high- 
est-priority job has been fulfilled, the dispatcher 
interrupts the processing job, places it in the 
wait queue, reinserts the highest-priority job, 
and returns control to it. 

There are a number of weaknesses associated 
with this type of dispatching scheme — the most 
prominent being that low-priority jobs are not 
considered for processing until all higher-pri¬ 
ority jobs have either run to completion or are 
in the wait queue. In more instances than not, 
the delay is unacceptable. Another drawback is 
that all jobs are given an undetermined amount 
of processing time. 


There are a number of approaches to solving 
these problems; but the most promising calls for 
the use of more than one queue, assigning a par¬ 
ticular job class to a particular queue, and vary¬ 
ing the length of the time slice to correspond to 
the class of job. This setup is used mostly with 
fixed partitions, and calls for the dispatcher to 
assign different job classes to different process¬ 
ing regions; processing is performed for the 
length of the time slice associated with the job. 
Since the time slice varies, higher-priority jobs 
usually get more processing time, and thus the 
validity of using different job classes is retained. 
However, since jobs are assigned to partitions, 
all have a reasonable chance of receiving some 
processing time. 

Information Files . The information files con- 
si sF^orTiles^orTEejTinay be libraries of pro¬ 
grams or subroutines. The allocation of each of 
these facilities is handled somewhat differently. 

Data files may be statically assigned to a job 
during the scheduling process and treated in 
much the same way as an I/O device assign¬ 
ment. Other systems permit access to the same 
data file by a number of concurrently executing 
programs. Here, the file is dynamically allo¬ 
cated based on the type of access the program 
requests (i.e., read only/write only). 

Programs or subroutines may be designated 
for exclusive use by 1 program, or they may be 
designated as shareable. Shareable data is loaded 
and executed as needed, rather than being incorpo¬ 
rated as part of the executing program during 
the binding process (which is the case of non- 
shareable programs). Shared routines may be 
loaded into a specially designated transient area, 
into any available main storage area, or made 
part of the resident system (the latter technique 
is used to handle frequently called routines). 

The allocation of subroutines to programs 
varies with the subroutine type. Nonreusable 
subroutines must be loaded "fresh” each time a 
request is made for the routine. Serially reus¬ 
able routines need not be reloaded; but due to 
possible modification of constants or instruc¬ 
tions, they can only be used by one program at 
a time. Reentrant routines may be used by any 
number of executing programs simultaneously. 
Thus allocation of reentrant routines is straight¬ 
forward, whereas serially reusable routines 
must have a lock/unlock facility which limits 
their assignment to a single program at a time. 

PROGRAM STRUCTURES 

Most operating systems support several kinds 
of program loading structures, the more common 
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being simple, overlay, dynamic, and paged. 
These structures obviously relate to the main 
storage allocation techniques previously 
described. 

A simple program structure consists of a 
single load module, which occupies a fixed 
amount of storage. (A load module, discussed 
later, consists of a collection of instruction 
sets.) An overlay program allows for repeated 
use of the same blocks of main storage during 
different stages of program execution. Thus the 
overlay program is segmented, and each seg¬ 
ment is loaded as required. 

Paged and dynamic structures are consider¬ 
ably more sophisticated in scope and, conse¬ 
quently, are common only in the larger multi- 
programmed and time sharing environments. 
Dynamic loading allows a relocatable module 
(i.e., one that can be loaded into any given 
storage location) to be loaded into main storage 
upon a request for that jnodule by an executing 
program. It differs from an overlay structure 
in that the area of main storage need not be pre- 
specified, nor does the module necessarily re¬ 
place or overlay an existing program segment. 

One of the major problems with dynamically 
loaded programs is that the process creates 
unused main storage fragments (a form of 
"checkerboarding”). The unused fragments re¬ 
sult when all dynamically loaded programs do 
not terminate concurrently. 

Load Module Generation 

Most compilers and assemblers do not di¬ 
rectly produce executable code. Rather, they 
produce relocatable code — generally an in¬ 
struction set coded in machine language — which 
requires resolution of certain deficiencies be¬ 
fore execution. For example, it may lack phys¬ 
ical main storage locations from which to oper¬ 
ate, or it may have unresolved linkage se¬ 
quences. The process of converting these pro¬ 
grams to a format which can be loaded and 
executed is called load module generation. 

Many systems can combine the relocatable 
code modules produced by various language com¬ 
pilers with subroutines and other relocatable 
code modules to provide a single load module. 
When combined, they are normally assigned to 
contiguous storage locations and the internal 
storage references within each module are ap¬ 
propriately modified. The intermodule linkages, 
whereby one object module transfers control and 
data to another, are then resolved by determin¬ 
ing the newly assigned storage locations of the 


respective modules and inserting these addresses 
into the linkage sequence. This process is 
known by a number of different names, but the 
more frequently used are binding, linkage 
editing, and collecting. 

Many systems also offer the capability to 
implicitly include relocatable elements. If any 
intermodule linkages are unresolved at the end 
of the linkage editing process, the system as¬ 
sumes that the unresolved entries are implicit 
calls for relocatable subroutines and initiates 
a search of the system library for subroutines 
of the same name. This feature is particularly 
handy for program code generating routines 
(such as compilers, data management systems, 
and report generators), since an explicit list of 
supporting subroutines need not be specified 
during code generation. 

PROGRAM CONTROL 

The degree to which operating systems con¬ 
trol program execution varies greatly among 
systems. Most provide dispatching control, 
interrupt processing control, event synchroniza¬ 
tion, and program limit monitoring. 

Dispatching control (already discussed) is 
responsible for allocating processor time to 
each task. 

Interrupt processing deals with the methods 
used to respond to different classes of inter¬ 
rupts . An interrupt is usually caused by an 
I/O event, program error, machine error, or 
operator-initiated call. In the overall scheme, 
there are 2 classes of interrupts: high level 
and low level. Processing is normally inter¬ 
rupted whenever high-level interrupts occur; 
low-level interrupts are usually held pending. 
Should a number of interrupts occur simulta¬ 
neously, they are queued and serviced according 
to priority. Stacking, however, can lead to lost 
interrupts, particularly when the interrupt queue 
size is limited. 

Interrupt acknowledgment can be altered by 
disabling interrupts to prevent recognition or by 
masking them to defer recognition. 

When an unmasked interrupt occurs, the 
current instruction is usually allowed to complete 
execution. The program and the contents of the 
machine registers are then saved in main stor¬ 
age and control is transferred to a program, 
which will service the interrupt. This program 
may complete execution, or in turn may be in¬ 
terrupted by a still higher-priority interrupt. 
When an interrupt processing program does com¬ 
plete execution, control is returned to the highest 


OPERATING SYSTEMS 


pending interrupt processing routine or to the 
supervisor dispatching routine if no interrupts 
are pending. 

Event synchronization simply means delaying 
task execution until some specified event occurs, 
or triggering a task when a specified event 
occurs. The most common types of events, 
which may delay or initiate task execution, are 
I/O completions, selected time intervals, sub¬ 
task completions, and unsolicited key-ins. 

Event synchronization may also be effected 
between several tasks of a job. One task may 
initiate any number of subordinate tasks and may 
execute concurrently with them. This main task 
may, at any time, issue wait requests which will 
suspend main task processing until one or more 
of the subordinate tasks have been completed. 

Program limit monitoring is the process of 
monitoring various resources during job execu¬ 
tion to ensure that certain specified limits are 
not exceeded. Limits are usually established 
for such elements as central processor time 
used, output records produced, and the amount 
of main and secondary storage space allocated. 
Some systems automatically cause abnormal 
job termination when any of the system limits 
for a particular job is exceeded. Others permit 
the user to specify the actions to be exercised. 

I/O Data Control 

Data Transfer and Buffering . Data transfer in- 
volves the movement of data between main stor¬ 
age and I/O devices. Before data can be trans¬ 
ferred, however, a buffer area must be set 
aside in main storage. 

The techniques for allocating a buffer area 
vary. Some systems — small ones in particular — 
and some languages require the applications 
programmer to suballocate parts of his main 
storage as buffer files. Three methods are used 
to accomplish this: single buffering, double 
buffering, and buffer pooling. 

Single or double buffering allocates either 
one or two fixed main storage areas as buffers 
for each designated file. The areas are allo¬ 
cated in advance and remain allocated whether or 
not the file is being processed. 

A buffer pool, on the other hand, is a large 
storage area containing several buffer areas. 

Each can be made available as an input or output 
buffer for any file. Whenever an I/O operation 
is required for a file, the user removes a buffer 


from the pool and assigns it to the file. When 
the data transfer and subsequent processing are 
complete, the buffer is returned to the pool. 

Thus, buffer pooling can reduce the total area 
required for user buffers if all files are not 
concurrently active. 

More sophisticated operating systems offer 
system-controlled exchange or dynamic buffer¬ 
ing facilities . Dynamic buffering provides buffers 
to an executing task in response to an actual 
demand for a buffer area. It is similar to buffer 
pooling, except that the system controls buffer 
allocation rather than the user. 

Exchange buffering eliminates the need to 
move data between a system buffer and user 
storage. In this type of processing, a system 
buffer is filled by a file input action. However, 
instead of moving this data to a user processing 
area, the system simply exchanges buffer areas 
with the application program. Similarly when 
a user buffer is full, the system exchanges it for 
an empty buffer and user processing continues. 
Exchange buffering allows complete system con¬ 
trol of buffer activity while minimizing system 
overhead. 

As data transfer operations occur, the system 
may have to initiate routines to translate data 
codes. This usually occurs in telecommunica¬ 
tions, where the I/O line data coding structures 
differ from the internal computer data codes. 

When code translation is required, it occurs as 
a part of the system interface to the I/O device. 
Thus differences in coding structures are gen¬ 
erally transparent to an applications programmer. 
Many smaller systems, however, do not provide 
this feature and thus it must be performed by 
the application program. 

In a time sharing or remote job entry environ¬ 
ment, the remote terminal is the main input and 
output device of the system. Thus, a capability 
is usually provided for the remote terminal user 
to communicate directly with the computer opera¬ 
tor via the terminal keyboard. 

Many systems supporting terminals also allow 
the various forms of operator-user and interuser 
communication. Here an operator can communi¬ 
cate with one, all, or selected users. A user 
can also communicate with the operator and other 
users. With this feature, the terminal users 
may inhibit message receipt by requesting the 
system not to forward messages from other 
users. Many systems also support a communi¬ 
cations area to store messages for a user to 
receive during log-on. 
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Recovery Processing 

Recovery processing deals with the system f s 
capability to recover in the event an error 
(usually nonprogramming in nature) occurs. De¬ 
pending on the nature of the error, the system 
may have to be completely restarted or restarted 
from the beginning of a particular job; or it may 
be able to restart execution from an earlier point 
in the job’s processing cycle. The latter capa¬ 
bility is usually called checkpoint/restart. 

Restarting functions are oriented towards 
restoring as much as possible of the system 
environment prior to the error’s occurrence. 
Checkpoints handle the recording of this informa¬ 
tion nicely. 

Checkpoint/Re start. Checkpointing is the re¬ 
cording of information about a program and its 
environment on secondary storage, so that at 
any future time the program may be reinitiated 
from that point. Small operating systems, par¬ 
ticularly serial processing systems, checkpoint 
all of main storage; while mostmultiprogrammed 
systems checkpoint only individual storage par¬ 
titions. The checkpoint record is maintained 
on an on-line (usually tape or direct access) 
checkpoint file and usually contains main storage 
contents. In addition, checkpoints can contain 
selected register settings, I/O device reposi¬ 
tioning requirements, and the contents of critical 
permanent and temporary data files. 

A checkpoint record is created whenever a 
request for a checkpoint is issued. The re¬ 
quest may be initiated by the operating system, 
by a problem program, or by the computer op¬ 
erator. In general, the operating system ini¬ 
tiates checkpoints to accomplish roll-in, roll¬ 
out processing or for automatic restarts in real¬ 
time environments. User programs usually 
initiate checkpoints only when system-directed 
checkpointing is not provided. The operator 
normally initiates a checkpoint when he must 
temporarily terminate system operations for 
some reason. 

Some systems only support checkpointing for 
certain types of jobs: for example, background 
but not foreground checkpoints. Many time 
sharing systems do not provide a specific check¬ 
point capability at all. However, some of these 
systems do allow the user to save the current 
status of his program for subsequent reloading. 
This could be considered a de facto checkpoint, 
since the program can be reinitiated from that 
point. 


Restarting is the process of restoring the 
status of a job to some previous point in time. 

The three basic types of restart capabilities 
used within all operating systems are checkpoint, 
task, and job. A restart taken from a checkpoint 
reestablishes the program and its data in the 
operating environment as they existed when the 
checkpoint was taken and resumes execution at 
the restart address included in the checkpoint. 

A task restart reinitiates processing from the 
beginning of the identified task. A job restart 
reinitiates processing from the beginning of the 
identified task or from the beginning of the en¬ 
tire job. 

Except in some cases where the supervisor 
checkpoints a program to provide roll-in, roll¬ 
out services, restarts normally require device 
repositioning. The extent to which devices may 
be repositioned varies, although most systems 
will, as a minimum, reposition sequential de¬ 
vices. Some systems also reposition direct 
access device arms and reestablish broken tele¬ 
processing line communications. Repositioning 
not performed by the system must be provided by 
the application program or the computer 
operator. 

REMOTE TERMINAL SUPPORT 

All time sharing systems and batch systems 
offering remote job entry offer some form of 
control over remote terminals. The degree of 
control varies with the ’’front-end” software 
offered by the system. These systems also pro¬ 
vide some sort of line-service software package 
to supplement the normal data transfer routines. 
Some systems, for example, only provide for a 
standard terminal processing speed and format, 
while others offer a mix of line speeds in addi¬ 
tion to such features as CRT paging and data 
compression. 

PROCESSING SUPPORT 

Most operating systems provide at least one 
if not all of the following processing support ser¬ 
vices: error diagnostics, time services, and 
testing and debugging services. 

Error Diagnostics 

Diagnostic error processing deals with rec¬ 
ognizing hardware and program errors, and pro¬ 
viding routines to handle them. 

Most systems provide hardware error control 
routines to recognize and handle main storage 
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parity errors, processor errors, I/O control 
memory errors, I/O data errors, and power 
failures. These are rather ’’stock” routines, 
however, and therefore may not be appropriate 
for the needs of the installation. 

For example, when an error occurs, control 
is transferred to a routine to determine its cause 
and in some cases the extent of the damage. If 
the error is minor, the system generally re¬ 
attempts the operation to determine if the error 
is permanent or transient. Permanent errors 
require some form of operator intervention. 

If the error is transient, a tally is kept of 
errors originating from an element to indicate 
which are producing a relatively high level of 
transient errors. This information can then 
be evaluated to determine which elements are 
going ’’soft, ” so action can be taken to head off a 
serious failure that might destroy data. 

The more sophisticated systems dynamically 
reconfigure components in the event of an error 
that affects overall system performance. This 
capability removes failing components and re¬ 
places them with backup units. If no backup is 
provided, some systems employ what is called 
’’fail-soft” technology. With it, when a hardware 
component fails, it is marked unusable and the 
system continues performing with less hardware. 
Since this almost always reduces the workload 
the system can handle, lower-priority jobs are 
either not serviced or serviced less frequently. 

Just about every operating system has facili¬ 
ties for recognizing program errors, but the 
techniques used to handle them vary with the 
seriousness of the error. Generally, users are 
permitted to use their own routines to handle 
minor errors — such as those in arithmetic and 
data. Serious errors, that is, those which 
threaten the integrity of the system (such as a 
core storage violation) are handled by system 
routines. Serious errors generally result in 
abnormal termination of the offending program. 

Time Service 

Most systems have an internal timing device 
to provide timing services to the application pro¬ 
grams. Such services are of two types: interval 
timing and real-time. 

Interval timing services are used to suspend 
processing for specified times or to alert the 
program when a specified time interval has 
passed. Thus, such services are used to sched¬ 
ule intermittent checks for specified conditions 
or to prevent unending program loops. 


Real-time clock services are most frequently 
used to provide the date and time of day to exe¬ 
cuting programs. However, they may also be 
used to schedule interrupts at specific times 
(rather than intervals) so that events can be 
scheduled or terminated on a time-of-day basis. 

Testing and Debugging Service 

The facilities available for testing and de¬ 
bugging application programs vary considerably. 
Some provide an independent program testing and 
debugging package that operates in conjunction 
with the resident operating system. Others in¬ 
corporate testing and debugging support as a 
part of the resident system service package. 

Many systems maintain two distinct user 
operational modes, a normal mode and a testing 
mode. When errors occur under a normal mode, 
the program terminates abnormally. However 
under a testing mode errors trigger a series of 
debugging routines that gather selected informa¬ 
tion about the error condition. The advantage 
of a test mode is that it provides for an orderly 
handling of error conditions without immediately 
invoking the system’s abend routines. 

Storage dumps allow the user to display all 
of core or only specified portions. Dumps are 
frequently initiated during the execution of a pro¬ 
gram (snapshot dumps) as well as upon termina¬ 
tion of the program (postmortem dumps). Gen¬ 
erally, these dumps are highly formatted and 
are oriented to providing as much information 
about program status as can be presented. 

Tracing facilities provide a sequential history 
of program execution. In general, the history 
records each particular instruction being exe¬ 
cuted, its address, the data fields affected, and 
their contents before and after the operation. 
Although there are many different types of traces, 
they generally display the same types of informa¬ 
tion and are only distinguished by the occurrences 
that cause the information to be displayed. Sev¬ 
eral common types of traces are full instruction 
tracing, instruction tracing within specified 
address limits, traces of interrupt occurrences, 
supervisory entry and exit sequences, and traces 
of instructions that modify selected words in 
main storage. There are also traces whereby 
the contents of a defined data area are displayed 
whenever they change. 

In an interactive time sharing environment, 
testing and debugging facilities are usually quite 
extensive. Here the terminal user can examine 
and modify task elements such as instructions, 
numeric values and coded information, insert 
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breakpoints into a task, and control execution by 
directing or redefining the instruction executing 
sequence. 

Logging and Accounting 

Most systems provide accounting and statis¬ 
tical information on job execution and resource 
utilization. Generally this function simply re¬ 
cords the following information at the termina¬ 
tion of each job: job identification and termina¬ 
tion status, number of records added to or de¬ 
leted from each permanent file, CPU time uti¬ 
lized, time used by each channel and each de¬ 
vice, number of lines printed, number of cards 
punched, and number of records written on sys¬ 
tem output units. 

DATA MANAGEMENT 

Data management functions consist of file 
management, I/O support, and data management 
system facilities. A file is defined as a collec¬ 
tion of data records. File management facilities 
provide file support for the system files as enti¬ 
ties rather than for the individual data records 
within the files. Support for the latter is pro¬ 
vided by the other 2 data management categories. 

I/O support facilities enable a program to 
access and process individual data records within 
the file. These facilities are normally invoked 
by using macroinstructions within the problem 
program and eliminate the need for programmers 
to be concerned with many of the problems of 
reading and writing data records. 

A data management system consists of routines 
that create, maintain, and interrogate an orga¬ 
nized collection of related data known as the data 
base. A data management system creates files 
from various input sources, and maintain these 
files by additions, deletions, and alterations. 

It also creates new files, reorganizes, and 
merges existing files, and selects data via user- 
prepared queries. In addition it makes computa¬ 
tions on this data and produces reports in sys¬ 
tem-defined or user-specified formats. A data 
management system may be designed to operate 
in either batch or interactive mode. 

Data management systems also allow a user 
with limited programming interests to perform 
such operations as retrieving and displaying 
selected data records in the file. 

Generally, data management systems are 
adjuncts to an operating system and are more 
or less self-contained, depending on the archi¬ 


tecture of the particular system. Consequently, 
a data management system will make use of 
many of the features provided by other operating 
system functions in its own internal design. 

File Management Facilities 

File management facilities are oriented 
toward controlling the various data files within 
the system. The file management functions are 
invoked to locate on-line and off-line files, per¬ 
mit or restrict user access to files, and to pro¬ 
vide backup and restoration services in case of 
file damage. 

In most systems permanent data files are 
identified by labels assigned by the user or the 
system. File labels may contain a file identifier, 
the file edition number, the owner’s name and 
account number, and perhaps a file utilization 
privacy code. Some systems permit file names 
to be a composite of several names in order to 
provide hierarchical levels of file indexing. 

In larger batch processing and time sharing 
systems the location of all permanent data files 
known to the system is usually maintained in a 
master directory or catalog. A file can then be 
located for processing by searching the master 
directory of on-line and off-line files. 

If the system does not maintain a directory, 
a sequential label comparison must be performed 
physically against each on-line file until the de¬ 
sired file is located. In addition there is usually 
no capability to locate off-line files; instead they 
must be presented to the system by the operator. 
Obviously, systems without directories contain 
some severe drawbacks. 

File Backup 

Most file-oriented systems provide some 
form of file backup facility to recover from inad¬ 
vertent damage to the file system. This facility 
usually consists of checkpoint files, transaction 
data files, and previous versions of the data 
file (grandfather files). These files may be 
available to the system on either an on-line or 
off-line basis. Restoration functions may be 
initiated automatically by the system or may re¬ 
quire operator intervention. 

I/O Support Facilities 

I/O support exists for most systems on two 
levels: physical and logical. Physical I/O, the 
basic level, is provided by routines that initiate 
the actual data transmission and provide program 
access to the data in the format of transmissions. 
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Logical I/O, the extended level of support, 
allows manipulation of data without regard to the 
physical structure of the data. Thus it serves as 
an intermediary between user data-handling op¬ 
erations and the physical I/O services of the sys¬ 
tem. Most systems provide physical I/O support 
and all but the smallest systems provide logical 
I/O support. 

File Structures 

The most common file structures are sequen¬ 
tial, hierarchical, indexed, list, and ring. A 
sequential structure is one in which the data 
elements are all of equal rank and maintained in 
a serial order. In a hierarchical structure, the 
data elements are classified and stored according 
to a ranking scheme. An indexed structure is 
one in which portions of the file are reserved as 
keys to locate information in other parts of the 
file. A list structure is one wherein each data 
element contains the address of, and thereby 
points to, a successor element. A ring structure 
is a circular list structure in which the last 
data element points back to the first. 

These file structures should not be confused 
with the access methods discussed later. The 
access methods relate to the set of routines a 
programmer may use to store and retrieve data 
records from second storage devices. The data 
management file structures refer to a type of 
file organization that permits a user to classify 
and store data. The data management routines 
utilize whatever access methods are available to 
implement the various file-structuring forms. 

File Storage Allocation 

Techniques for allocating file storage areas 
vary widely from system to system. The more 
sophisticated systems dynamically allocate and 
reallocate storage as required; many systems 
leave this function almost entirely to the user. 

In the latter case, associated functions such as 
protection from inadvertent destruction may 
also be under user control. 

File Access Methods 

The most common file access methods sup¬ 
ported are the sequential, indexed, keyed, ran¬ 
dom, and telecommunications organizations. 
Each method can provide for data storage and 
retrieval on a physical or logical record level. 

Sequential access processes records serially 
and reads or writes them consecutively on a 
storage volume. Sequential access may be pro¬ 
vided for data stored on any secondary storage 


medium, although certain storage media, such 
as magnetic tape, obviously dictate a file orga¬ 
nization of this type. 

Indexed access methods create and maintain 
files which, in addition to the data records, have 
directories of selected record field values and 
their corresponding record addresses. Records 
may then be located by searching the directory 
rather than the file. Some form of immediate 
access storage, such as disc is needed for in¬ 
dexed access methods to have value. 

Keyed access methods use a selected data 
field within each record to uniquely identify the 
record. This data field, called the record key, 
usually corresponds to the record identification 
code. Keyed access is useful for secondary 
storage devices that employ hardware-imple¬ 
mented search instructions. A record request 
causes the read/write mechanism to scan the 
entire file in search of a selected record key. 
Consequently, processor time need not be wasted 
scanning secondary storage. This technique is 
frequently augmented by software that isolates a 
portion of the file prior to issuing the keyed 
search in order to avoid a scan of the entire file. 

Random access methods read and write rec¬ 
ords without regard to the physical sequence in 
which they are stored. Thus stored records 
must have some type of identification code that 
enables the record location to be determined. 
Usually, an algorithm is employed to convert a 
unique record identification into a unique storage 
address on an immediate access storage device. 

Telecommunication data is usually composed 
of character strings of varying lengths. While 
not a file in a classical sense, most systems 
provide assistance in accessing and processing 
the relatively unformatted messages that accu¬ 
mulate in the system communication buffers. 

This assistance normally handles all communi¬ 
cation between the computing system and remotely 
located terminals. The functions performed 
include allocation of storage for message buff¬ 
ering, polling terminals to determine if any 
have messages to send, recognizing message 
priorities, analyzing message headers to deter¬ 
mine where input and output messages are to 
be routed, checking the sequence number of in¬ 
coming messages, checking transmission errors, 
and maintaining input and output message queues. 

Data Blocking and Deblocking 

Blocking combines two or more individual 
records into one physical data block. Deblocking 
isolates the individual records within a physical 


data block. Record lengths may be fixed, vari¬ 
able, or undefined, and all of the types may be 
blocked or unblocked. Blocked records require 
larger I/O buffer areas, but provide greater 
storage utilization. 

Operating systems providing only physical I/O 
support require the user to perform his own rec¬ 
ord blocking and deblocking functions. Systems 
that provide logical support allow the user to op¬ 
erate on all data at the individual record level 
without regard to the structure of the physical 
block. Blocking and deblocking are usually ac¬ 
complished by moving data between the I/O buff¬ 
ers and a user processing area or by using spe¬ 
cial location pointers to isolate and process in¬ 
formation within the buffer. 

DATA HANDLING UTILITIES 

The data-handling utility programs are gen¬ 
erally fairly simple routines which are activated 
by a program call, a system control card, or an 
operator key-in. These utilities rarely interface 
directly with an executing program, though they 
are frequently included as a separate job step 
in a multistep job. There are two general classes 
of data handling utilities: display and peripheral 
support. 

The most common display facilities provided 
are for main storage, system catalogs, tables, 
and directories. Other display facilities are 
generally provided for data stored on any secon¬ 
dary storage media supported by the system. 
Typically, these include tape to printer and disc 
to printer data conversions. Since these media 
conversions are normally performed expressly 
for visual display, they often incorporate special 
formats and visual aids in addition to simple data 
translation. Generally, the formats and visual 
aids are predetermined, although some systems 
allow the user to influence the output by exer¬ 
cising certain options (e.g., interfacing with a 
user-written program to control formatting on 
the basis of user defined editing characteristics 
included in the data). 

Peripheral device support utilities perform 
such functions as volume positioning, media con¬ 
version, data editing, and test file support. Vol¬ 
ume positioning may be used to backspace, for¬ 
ward space, or rewind a magnetic tape; to locate 
a file on a tape or direct access volume; or to 
locate a specific record within a file, including 
the end of the last record. 


The media conversion facilities permit data 
to be copied from one secondary storage medium 
to another. Generally, these facilities are pro¬ 
vided for all combinations of peripheral devices 
supported by the system, viz., card to tape, 
tape to card, and tape to disc. Transfers be¬ 
tween media may, of course, be accompanied by 
additional formatting or data translation, espe¬ 
cially when the receiving device does not support 
the data organization of the sending device (e.g. 
hierarchical disc to tape). Unlike the display 
facilities, however, these transfers are not 
performed expressly for humans; thus media 
conversion tends to be straightforward and occurs 
within the limits of the media involved. A card- 
to-tape conversion may be expected to duplicate 
the data from each card in sequential 80-char- 
acter tape records. 

An extension of the media conversion facilities 
provides facilities for dumping and reloading sec¬ 
ondary storage. These facilities are generally 
employed for backup file creation and for storage 
compaction. 

Additional data handling features available 
in many systems support file rather than device- 
oriented processing. These features are in¬ 
cluded here, however, due to their basic simi¬ 
larity to the media conversion facilities. For 
example, data editing facilities permit the user 
to scan a data file to detect logical data errors 
(e.g., out-of-sequence conditions) and to com¬ 
pare files residing on separate media. Further¬ 
more, several systems provide test file support 
utilities which can be used to develop device- 
oriented data files for use in application program 
testing. 

SORTING AND MERGING 

Programs that sort or merge sets of data rec¬ 
ords normally comprise a part of the operating 
system. The sorting function takes strings of 
unordered records and sequences them according 
to a user-specified collating sequence for given 
key or set of keys within each record. The 
merging function, on the other hand, takes sepa¬ 
rate strings of records which have already been 
ordered by keys and produces a composite 
ordered output string. 

The design of most sort programs is such that 
the unordered records are placed into ordered 
strings and then merged. Consequently, a single 
program usually suffices to perform both 
functions. 
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BURROUGHS 

Master Control Program V (MCP V) 


GENERAL 

Master Control Program (MCP), the designa¬ 
tor for the operating system used with Burroughs 
medium- and large-scale computers, is a disc- 
resident collection of programs and routines de¬ 
signed to handle processing in a multiprogram¬ 
ming and multiprocessing environment. Versions 
are offered to service standard batch, data com¬ 
munications and MICR/OCR applications. The 
data communications and MICR/OCR features 
must be SYSGENed and require an additional 20K 
and 10K bytes respectively. 

All versions of the MCP perform loading, in¬ 
terrupt processing, I/O control, selection and 
initiation of programs on a priority basis, I/O 
error processing, system log maintenance, both 
input and output data spooling, dynamic storage 
allocation for core and disc, and overlay func¬ 
tions. Any version may be used as a multipro¬ 
cessing operating system on the B 4700 by em¬ 
ploying Burroughs’ shared-disc capability and 
by configuring the selector channel controllers 
so that they are associated with different proces¬ 
sors. The shared-disc capability allows any rec¬ 
ord, in any file, on any disc to be shared without 
having to allocate specific units to specific 
systems. 

The latest version of the MCP, called MCP V, 
was introduced in April 1972. Designed for 
B 2500, 2700, 3500, and 4700 machines, it re¬ 
tains all of the capabilities of previous releases 
and has been enhanced to increase system 
throughput and reliability. 

To increase throughput, both the logical and 
physical I/O code paths have been optimized to 
complement Cobol blocking/unblocking techniques 
employed in user programs. To ensure maxi¬ 
mum efficiency, the code required to handle the 
file accessing techniques has been divided into 
separate logical paths. To reduce MCP delays, 
all MCP I/O requests are now handled by the 
queuing structures; this allows a waiting program 
not requiring that overlay area to be reinstated. 

To enhance overall system performance, the 
MCP nucleus area has increased to hold more 
critical routines, while the overlay area has been 
decreased. Where MCP 4.5 required a minimum 
of 30K bytes of main memory (13K for nucleus 
and 16K for overlays). Version V requires at 
least 50K — of which 44K is nucleus. As with 
previous versions of the operating system, the 
new one also fills unused portions of main stor¬ 
age with frequently called overlays. 

To improve user program performance in a 
multiprogramming mix, a new priority schedul¬ 


ing scheme has been introduced which allows 
separate priorities for scheduling, memory utili¬ 
zation, and processor usage. By careful planning 
and thorough job analysis, users can fine tune 
their systems to attain the optimum processing 
order of jobs which best use system resources. 
(See DESCRIPTION AND EVALUATION.) 

MCP V also contains features which maintain 
system integrity. Critical fields, for example, 
have been removed from user program File In¬ 
formation Blocks (FIB) when a file is opened — 
thus eliminating a common source of pro- 
grammed-caused failures. Validity checks are 
now made on other fields within the FIB. 

Other major features new and unique to MCP 

V are a shared disc capability and the storage 
queue (STOQUE). With shared disc, up to four pro¬ 
cessors may share the same data base. STOQUE 
is a data transfer mechanism for asynchronous 
interprogram communication and provides many 
of the benefits of independently compiled modules. 

High level languages supported consist of three 
Cobol and three Fortran compilers and an Algol- 
like compiler called BPL. The latter is available 
on the B 4700 only. 

The Cobol compilers offered are a straight 
ANSI Version (17K bytes) and two Burroughs en¬ 
hanced versions: Cobol L (30K bytes) and Cobol 

V (45K bytes). Cobol L is not new; Cobol V is. 
Cobol V is designed to effectively use a series of 
new B 4700 hardware operators and to take advan¬ 
tage of the extended addressing capabilities of 
the B 4700. The combination of the new compiler 
and the extended features permits programs as 
large as 750K bytes. Programs written for the 

B 2500/3500 are syntactically compatible with 
Cobol V. 

The available Fortran compilers are Fortran 
II, requiring 40K bytes; Fortran IV, requiring 
27K bytes; and Fort IV, requiring 45K bytes of 
core. Fort IV, a new compiler, includes all of 
the capabilities of Fortran IV level H for the 
System/360 and B 2500/3500 Fortran. The code 
generated includes extended addressing which 
allows programs as large as 150K bytes to be 
constructed. 

The BPL is an Algol-like language which 
makes all hardware capabilities available at the 
machine level. Constructs are provided for all 
MCP interfaces, thus giving the compiler the 
capabilities of assembler plus the advantages of 
a high-level language. No core sizes are avail¬ 
able for BPL. 
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Operating Environment 

Medium scale computers with a minimum of 
one card reader, a magnetic tape unit, a console 
keyboard printer, and one head-per-track disc. 
Minimum operating system requirement is 50K 
bytes of main memory, of which 44K is reserved 
for nucleus routines. Source language is Cobol. 

FUNCTIONAL CHARACTERISTICS 

Job Types 

Batch, data communications, M1CR. 

Job Scheduling 

Tri-priority scheme based on job priority, 
memory utilization and processor usage. (See 
DESCRIPTION AND EVALUATION.) Up to 15 
jobs may be processing concurrently. 

Resource Allocation 

Main Storage: dynamically assigned, fixed 
size regions; core compression performed as 
needed. 

CPU Time: fixed 200 msec time slices per 
job. I/O Devices: dynamic assigned from com¬ 
mon pool. 

Information Files: dynamically allocated; 
shareable and nonshareable programs and sub¬ 
routines permitted. 

Program Structure and Loading 

Simple structure or user specified variable 
size overlays; all programs compiled at base zero 
and disc addresses assigned by MCP. 

I/O Control 

Device Types: disc, magnetic tape, type¬ 
writer, unit record devices, MICR, video display. 

Scheduling Performed: physical device only. 
Input data spooled to disc; output data spooled 
tape or disc. 

Buffer Allocation: dynamically assigned as 
needed. 

Remote Terminal Support: standard terminal 
speed and format. 


Recovery Processing 

Checkpoint/restart all jobs; roll-in, roll-out 
all jobs; serial and direct devices automatically 
repositioned. 

Diagnostic Error Processing 

Hardware and program errors recognized and 
serviced; minor errors retried before termina¬ 
tion; failed components marked inoperative and 
components reconfigured. On-line diagnostics 
tests for bad disc heads or disc surfaces. 

Processing Support 

Timing Services: interval and real-time. 
Testing and Debugging: postmortem and snap¬ 
shot dumps. 

Logging and Accounting 

Standard Accounting Data; accounting routines 
provided; no hardware error statistics kept. 

File Management 

Indexed libraries of macro code, source code, 
relocatable code, executable code; cataloging is 
dynamic. 

File Structure 

Sequential, indexed random, list and ring. 

File Storage Allocation 

Auxiliary storage size defined by user; stor¬ 
age assigned dynamically. 

File Location 

File name only using master catalog; no hier¬ 
archical structure permitted. 

File Access Methods 

Serial, random, and index random. 

Job Control Language 

Verb oriented, with reserved words that give 
it a self-documenting ability of a higher-level 
language. Closely resembles Cobol in appear¬ 
ance. Control cards consist of two classes: pro¬ 
gram control and program parameter cards. 
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• Program control cards specify the specific 
programs and data resources to be used 
(COMPILE, EXECUTE, DATA) as well as 
a delimiter card. Some data set utility 
functions (LOAD, DUMP) are also included. 

• Program parameter cards specify the 
system resources in terms of priority, ac¬ 
counting charges, core requirements, and 
file cards needed to run programs. They 
also control the execution of a program 
(START, STOP), and can change pro¬ 
gram values (INSERT) under certain 
circumstances. 

Sorting and Merging 

The sort and merge routines, with the excep¬ 
tion of the Sort V, are separate from the MCP, 
but operate in conjunction with it. The sort/ 
merge generator is quite flexible, allowing the 
user to tailor the sort routine for the most effi¬ 
cient execution. 

The sort program can be employed with tape 
or disc. With disc sort, 1 of 2 different types of 
sorts may be performed: a record sort or tag 
sort. A record sort yields logical record files. 

A tag sort yields records which are actually 
pointers to the file used to create them. The 
tape sort performs a record sort, and yields log¬ 
ical record files. 

Sort V is a new sort intrinsic, and is bound 
into MCP V. This sort is designed to realize a 
significant speed increase particularly in sorting 
fixed length records which are considerably 
larger or smaller than 100 characters and vari¬ 
able length records. Other features include the 
ability to specify disc assignment techniques for 
work files, and a translate option which sorts a 
user-specified collating sequence. 

Recompilation of existing programs is not 
necessary in order to use the new sort intrinsic. 
However, the minimum core required for execu¬ 
tion of a program which uses the sort intrinsic 
is increased to 30K bytes. Programs compiled 
prior to MCP V which were assigned less than 
30K bytes must be executed with a Core control 
instruction. 

The maximum record length for input to the" 
sort intrinsic is 4,998 characters. The maxi¬ 
mum blocking factor permitted is 999 records 
per block. The maximum block size is 4,998 
characters. Thus, the record size (4,998 char¬ 
acters or less) times the blocking factor (999 or 
less) cannot exceed 4,998 characters. A maxi¬ 
mum of 40 keys may be specified for a sort with 


the total length of the keys restricted to a maxi¬ 
mum of 290 bytes. 

The merge program merges from 2 to 8 files, 
provided the files are in the desired sequence. 
Records are read directly to memory, compared 
on the specific sort key, and written in sequence 
to the output tape. 

DESCRIPTION AND EVALUATION 

For overall ease of use, MCP has much to re¬ 
commend it. The system, for example, employs 
dynamic techniques to allocate resources; auto¬ 
matically reconfigures the system when hardware 
components fail; requires no complex JCL; and 
offers an extremely useful feature called auto¬ 
matic volume recognition (AVR). With AVR, the 
device assignment responsibility for handling 
files is automatic. To add a file on magnetic 
tape, for example, the operator mounts the tape 
on any convenient tape unit; MCP reads the file 
label, associates it with the unit, and assigns it 
a table location. Thus it is able to fetch the file 
when the program calls for it. MCP also assigns 
scratch tapes automatically. 

The following paragraphs highlight the 
strengths and weaknesses of MCP V, and elabo¬ 
rate on some of its more notable features. 

Job Scheduling 

The job scheduling scheme employed by MCP 
V is entirely different from that used by other 
releases of that operating system. The scheme 
is also potentially one of the most sophisticated 
on the market. We say potentially, for many 
users may have neither the need nor the "sophis- 
tication ,T to implement the new priority schemes. 

Essentially, a tri-priority scheme may be 
used to allow a job to gain control of the CPU. 
Jobs are scheduled based on: its scheduling 
priority; how well it will use memory; how effi¬ 
ciently it fits into the processing mix. 

When all are used, the schedule priority de¬ 
termines the sequence in which jobs are brought 
into the mix; up to 80 jobs may be in the mix at 
one time. The process priority determines the 
sequence in which programs are inserted or re¬ 
instated into the mix. And the memory priority 
determines the ability of a program to obtain and 
hold memory resources. All priorities carry 
user assigned numeric scheduling weight, rang¬ 
ing from 1 (lowest) to 9 (highest). 

The schedule priority scheme is the simplest 
to implement and is the same as the old numeric 
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scheduling scheme employed by MCP 4.5. A 
job's priority is assigned by the user, or in de¬ 
fault by the operating system, and a priority can 
be changed at any time by an operator instruction 
issued either from the console or via the card 
reader. A job's position within its respective 
entry queue is determined on a first-in, first-out 
basis (FIFO). The servicing of jobs, i.e., sched¬ 
uling them for execution, is performed round- 
robin intraqueue and straight priority interqueue. 

The process priority, as was previously 
stated, determines the sequence in which pro¬ 
grams are inserted or reinstated into the mix 
(in case the job was crashed out in favor of p 
higher priority job). In essence, its only func¬ 
tion is to resolve resource competition by allow¬ 
ing the higher priority job to run. Priorities may 
also be changed by the operator. 

The memory priority determines if a process¬ 
ing job should be permitted to hold memory in the 
event of a conflict. For example, say 2 pro¬ 
grams are competing for memory, and one has a 
schedule priority of 5 and a memory priority of 
4 while the other has a schedule priority of 4 and 
a memory priority of 9 (the highest). The first 
program brought into the mix would be the one 
with the highest scheduling priority, in this case 
5. If insufficient core is available to allow the 
job to run, programs with a memory priority be¬ 
low 4 would be rolled out. When the second job 
enters the mix, jobs with a memory priority of 
less than 9 would be rolled out if necessary. The 
operator may change this priority also. 

To use the process and memory priorities ef¬ 
fectively, users obviously will have to examine 
their jobs more carefully to look for such things 
as device contention, overlapping run times, 
availability of resources, etc. He essentially 
must fine tune the job mix to eliminate conflicts. 
In many instances, particularly where large 
volatile job mixes are involved, this task can be 
formidable if not impossible to accomplish. If 
the user is sharp enough, he can attain fantastic 
throughput; otherwise he could easily create a 
condition where the operator will constantly have 
to change priorities to eliminate conflicts, thus 
adversely affecting throughput. 

If the user wishes to stay away from the mem¬ 
ory and processing priorities for the time being, 
he may employ just the schedule priority 
scheme — in which case he may also have prob¬ 
lems. You see, jobs are scheduled based on the 
numeric priority assigned by the user, with 
higher priority jobs being scheduled before those 
with a lower number. In fact, a high priority job 
will crashout from processing one or more lower 


priority jobs to appropriate their resources if 
necessary. This indiscriminate crashing is a 
bad feature, in our opinion, for the lower-priority 
jobs could easily be making better use of the re¬ 
sources than crashing job will. Add to this a 
condition where 2 or more jobs must be crashed, 
and the result is poor utilization and reduced 
throughput. 

Now we are not suggesting that a forced-inter¬ 
rupt capability is in itself a detrimental feature. 
Quite to the contrary; it’s a valuable capability 
when properly used. We are suggesting that the 
temptation for the programmer or operator to 
invoke it could be significantly reduced if more 
careful job scheduling were done at the installa¬ 
tion to insure that lower priority jobs have a fair 
chance of being scheduled. Possible solutions 
would be a start-time limit, pass-over limit, or 
a priority weighting scheme which would consider 
priority and how the job will effect overall 
throughput and resource utilization. 

Resource Allocation 

System resources — internal storage, I/O 
devices, and information files — are automati¬ 
cally assigned according to need. Assignments 
take place on a priority basis, with the system 
keeping track of all assignments. Likewise, the 
system frees resources upon task completion. 

As sufficient resources become available they are 
assigned to the highest ranking jobs. 

Internal storage is maintained in a common 
pool and assigned to programs as needed. The 
amount of core allocated is determined by the 
maximum amount of code which must be core 
resident during program execution. 

Main Storage. Core is assigned in contiguous 
blocks, the base-limit addresses of which are 
determined by MCP. Registers within the pro¬ 
cessor indicate the bases of the various areas 
during program execution. MCP accommodates 
programs organized into segments of varying 
sizes, as opposed to fixed-size programs. A 
segment dictionary (a table containing 1 word for 
each program segment) tells whether the segment 
is in memory or on disc, and gives the corre¬ 
sponding main memory or disc address. Hence, 
no linking is required. 

Jobs are assigned core in accordance with 
their ranking in tri-priority scheme. The high¬ 
est ranking job is entered first, with lesser rank¬ 
ing jobs following. Prior to assigning a job, the 
system compares its core requirements with the 
amount of contiguous core available. If the job 
fits an available area, it's entered. Otherwise, 



all priorities being equal, the next ranking job is 
considered, and so on. 

When sufficient contiguous core is not avail¬ 
able, MCP checks the amount processing jobs 
have been assigned to determine if any is unused. 
If so, core compaction is performed by reorga¬ 
nizing all processing jobs to fill vacant areas, 
and then resetting the base-limit registers to re¬ 
flect the new locations of these jobs. 

These methods of assigning core lead to 
checkerboarding, even when compaction is done.* 
For example, suppose 18K bytes of contiguous 
core exist and the highest ranking job needs 16K. 
That job is entered and 2K is wasted. 

Core compaction won’t solve the problem 
either, for 2 reasons: (1) the programs used 
must be in the form of root segments and over- 
layable segments, and (2) enough contiguous core 
must be reserved to hold the root plus the largest 
overlayable segment combination — regardless 
of whether or not the overlay is core resident. 
When it is not, the core is unused and the check¬ 
erboard occurs. 

A possible solution to checkerboarding is to 
assign only enough core to hold the program root 
and the currently used segment. Although this 
adds to system overhead, it could pay for itself 
especially in a large multiprogramming mix. 

Core Sharing. MCP permits core sharing, a 
technique whereby multiple copies of the same 
program share a common area of core memory. 

It was used for interactive processing in conjunc¬ 
tion with the Command and Edit Language 
(CANDE) and the Basic compiler. In addition, 
MCP V includes the following enhancements: 
asynchronous information exchange between pro¬ 
grams (extremely useful for on-line message 
processing); straight-line code for I/O routines 
(instead of the use of generalized routines); im¬ 
proved directory handling; and support for 
shared-disc operations. 

Disc Management . A checkerboarding prob¬ 
lem that plagues many other systems does not 
exist with MCP V — viz., disc checkerboarding. 
Essentially, disc checkerboarding occurs when 
the data currently resident is smaller than the 
area originally reserved for it (IBM’s ISAM has 
this problem). These holes exist because the 
entire program is not loaded at once, and/or be¬ 
cause program data has been deleted from disc 
during processing. 


*Core compaction is not done for data communi¬ 
cations and MICR jobs. 


This problem does not occur with the Bur¬ 
roughs systems, for contiguous disc areas need 
not be reserved for programs. 

For example, a program which will ultimately 
require 100K bytes of disc need not tie up a con¬ 
tinuous portion of auxiliary storage if only 20K 
bytes are entered initially. Rather, MCP allo¬ 
cates only the needed space, records its location 
in the disc directory, and goes on to service 
other programs, placing their data in the next 
vacant area. When an earlier recorded program 
enters additional data for storage, MCP places 
it in a currently available area, records its loca¬ 
tion, and establishes pointers to other related 
recorded data. A separate file may occupy up to 
20 different areas on disc. An end-of-file pointer, 
contained in the disc directory, indicates the size 
and blocking factor of each record and the number 
of records in each area. 

Shared Disc . MCP V’s shared disc capability 
permits a system to be configured with up to 4 
processors accessing the same disc subsystems. 

A shared subsystem must be equipped with a file 
protect memory to insure the integrity of the data 
base since multiple programs may update the 
same data file concurrently. 

Shared disc constructs allowed are: 

• Read with lock — reads a record and locks 
out all other programs from accessing the 
record. 

• Read until unlock — same as above except 
record is not locked. 

• Read — reads record into core even if it is 
locked. 

• Lock — locks record but does not read it 
into core. 

• Write — writes record to disc and unlocks 
record. 

• Unlock — unlocks specified address, but 
does not write a record. 

• Write with no unlock — writes record but 
keeps it locked. 

• Seek with lock — seeks a record and locks 
it when found. 

• Seek — seeks a record whether or not it is 
locked. 

• Lock-seek — locks the record but does not 
read it into core; requesting program con¬ 
tinues if record is currently locked. 
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Storage Queue. To complement MCP V f s in¬ 
ter progranTcoinmunications facilities offered by 
core-to-core mechanisms, a storage queue 
(STOQ) function has been implemented. With 
STOQ, data can be transferred between programs 
in an asynchronous fashion. 

STOQ essentially queues data in a memory 
buffer external to all object programs, and re¬ 
trieves the data upon request. The queuing fea¬ 
tures of STOQ allows LIFO/FIFO queuing, trans¬ 
action buffering, intraprogram queuing, and pri¬ 
ority handling of transactions. 

Data Transfer 

Burroughs employs a unique system whereby 
each peripheral controller is serviced by an in¬ 
dividual channel — as opposed to sharing a chan¬ 
nel — connected directly to the main system. 

The advantage of using individual channels is that 
data transfer will never be delayed because the 
channel is busy, which is often the case with 
shared channels. 

Support Utilities 


The system support utilities provided as stan¬ 
dard features of the operating system are prin¬ 
cipally accounting based, allowing the system 
manager to analyze and distribute computer 
costs. The principal components of the system 
log and the time analysis and billing system 
(TABS). 

The logging and accounting routines rely on 
the system log to provide system usage data and 
on accounting routines to produce reports. The 


system log shows the job ID, its beginning and 
ending times, number of records read from and 
written to permanent files, CPU time prorated 
to a job, total chargeable time, lines printed, 
and type of job ending (normal or abnormal). 

A major enhancement provided by MCP V is 
the supervisory printer (SPO) log. The SPO log 
provides a copy on disc of all SPO messages. 

The file may be sorted into sequence by job, thus 
allowing quick reference by job. 

TABS uses the entries on the system log to 
analyze and disburse computer costs and related 
services, and generate relevant reports, the 
system also prints out reports showing the per¬ 
centage of peripheral device and CPU usage and 
by whom they were used. 

Another major enhancement supplied by MCP 
V is a field engineering maintenance log. This 
log records hardware errors and may be used 
by field engineers to identify components going 
soft. 

Hardware Reconfiguration . A feature carried 
over from previous MCPs is automatic hardware 
reconfiguration. Once a component fails, the 
system automatically marks it inoperative and 
reconfigures the remaining components to handle 
existing jobs. A truly outstanding feature, it is 
available on few operating systems. 
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GENERAL 

Extended Disk Operating System (EDOS) is in¬ 
tended to enhance, not replace, Release 26 of the 
Disk Operating System (DOS) used with the IBM 
System/360 and 370 computers. The enhance¬ 
ments, for the most part, consist of a new super¬ 
visor plus system and utility support programs. 
Other DOS elements, such as language proces¬ 
sors and access methods, are not altered with 
the basic version of EDOS. The vendor, however, 
does offer an optional 360/370 compatibility fea¬ 
ture that includes the complete 370 instruction 
set, permitting the use of access methods such 
as TCAM. 

The basic EDOS supervisor offers some sig¬ 
nificant advantages over the conventional DOS 
component: Load balancing, block fetching of 
program phases, and relocatable program mod¬ 
ules being among them. System improvements 
include three types of automatic volume sensing, 
cataloging of job control language statements un¬ 
der a unique procedure name, a new linkage ed¬ 
itor, and support that permits logical transient 
routines to be link edited directly with relevant 
programs. Optional EDOS offers the same su¬ 
pervisor and features are six-partition support 
and extended I/O spooling. 

These enhancements and others which consti¬ 
tute the difference between DOS and EDOS are 
discussed under DESCRIPTION AND EVALUA¬ 
TION. Unless specifically noted, all other op¬ 
erating characteristics and components of EDOS 
are those of the host operating system. (For 
complete coverage, refer to the AUERBACH re¬ 
port on the IBM System/360 and 370 Disk Oper¬ 
ating System.) 

Configuration Requirements 

Like DOS, the minimum system facilities 
needed vary with the application and options used. 
Support utility programs and their sizes are 
shown in Table 1. 

The rudimentary EDOS supervisor allows 
straight DOS type processing and is 10K bytes 
long. If all 12 basic EDOS utilities are specified, 
the size of the supervisor is increased by 2K 
bytes. Six-partition support also requires a 2K 
byte increase in the supervisor as does the ex¬ 
tended spooling feature. 129K bytes of main 
storage is considered the lowest practical limit 
for the six partition operation. Auxiliary stor¬ 
age requires the use of one 2311, 2314, or 2319 
Disk Drive for generation of the system. 

Price 

EDOS is available on a monthly lease, 12- 
month lease, or one-time license (see Table 2). 


Table 1. EDOS: Utility Programs 


Program 

Partition Size (kb) 

Min 

Optm. 

IPL System B 

16 

16 

Un-IPL System B 

16 

16 

AR/Dump 

16 

16 

AR/Summary 

24 

24 

AR/Swap 

16 

16 

Compiler Backup 

38 

38 

Compiler Workfile 

Initialize or 

Reinitialize 

16 

16 

Compiler Backup 

Tape Retrieve 

Programs 

38 

38 

Compile 

16 

16 

Document 

44 

44 

Linkage Editor 

16 

44 

Volume Dump 

44 

200 

Volume Restore 

44 

44 

Remote Job Entry 

12 

16 


The 360/370 compatibility feature (see Ex¬ 
tended Features) carries a one-time charge of 
$750. 

DESCRIPTION AND EVALUATION 

The features described under the following 
headings constitute the principal components of 
EDOS. It should be noted that these features are 
an integral part of EDOS and must be specified 
at system generation (SYSGEN) time. With the 
exception of six-partition support, and the ex¬ 
tended spooling, none are extra-cost options. If 
six-partition support is not desired, the system 
operates with three partitions as under conven¬ 
tional DOS. 

Six-Partition Generation 

The six-partition configuration of EDOS di¬ 
vides core into two logically independent sys¬ 
tems — A and B — consisting of three partitions 
each (foreground-one, foreground-two, and back¬ 
ground). Both systems are under control of the 
same supervisor. 

In operation, all six partitions can be pro¬ 
cessing concurrently and are serviced by way of 
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Table 2. EDOS Price Schedules 

System 

First Processing Unit 

Additional Processing Units 

Monthly 

Lease 

12-Mo. 

Lease 

License 

Monthly 

Lease 

12-Mo. 

Lease 

License 

Basic EDOS 

$260 

$225 

$6,750 

$85 

$75 

$2,250 

Six Partition 

100 

75 

2,250 

35 

25 

750 

Extended I/O Spooling 

240 

200 

6,000 

80 

70 

2,100 

360/370 Compatibility* 

— 

75 

— 

— 

25 


Remote Job Entry 

125 

100 

3,750 

— 

— 

— 

Each Addtl RJE Device 

75 

75 

2,250 

— 

— 

— 

*No charge for this feature after first year of use under 12-month lease plan. Charge for 
monthly lease or single charge license users is one-time charge of $750. 


the following priority scheme. Under System A, 
foreground partition one is the highest; fore¬ 
ground partition two, the next highest; and back¬ 
ground, the lowest. System B follows the same 
partition processing scheme, but all System B 
partitions have a lower priority than any parti¬ 
tion of System A. 

Like conventional DOS, the size of the System 
A partitions is specified at SYSGEN time and can 
be modified by the operator to meet changing 
processing requirements. Core requirements 
for System B, however, are indicated during a 
special initial program loading (IPL) operation. 
This program is loaded into the System A back¬ 
ground partition. The core required for System 
B is taken from the background partition of Sys¬ 
tem A in multiples of 2K bytes each. 

Figure 1 shows the arrangement of each 
partition after IPL of both systems. 

Any of the four foreground partitions may be 
allocated to OK bytes at any time; it should be 
noted however, that no two partitions with the 
same storage protect key should be contiguous, 
as this would a program in one partition to ac¬ 
cess the other partition with the same key. This 
restriction does not apply to the background 
partitions because of the 2K buffer between them. 
That buffer, incidentally, is the save area for 
System B and contains a protect key and tables 
for that system. 

After System B has been IPLed, BG-B is ac¬ 
tive and contains all the core available to System 
B. The system is available for processing in a 
normal DOS manner. Core can be allocated to 
and from other System B partitions without con- 


FOREGROUND 1 — SYSTEM A 
SP KEY=3 


FOREGROUND 2 — SYSTEM A 
SP KE Y=2 


FOREGROUND 1 — SYSTEM B 
SP KE Y=3 


FOREGROUND 2 — SYSTEM B 
SP KE Y=2 


BACKGROUND — SYSTEM B 
SP KE Y=1 


EDOS REQUIRED 2K BUFFER 
SP KE Y=0 


BACKGROUND — SYSTEM A 
SP KE Y=1 


SUPERVISOR 

SP KE Y=0 


Figure 1. EDOS: Partition Arrangement 


cern for the activities in System A. It should be 
noted, however, that batched job partition sizes 
under EDOS are higher than those required under 
DOS — 16K as opposed to 10K bytes; the addi¬ 
tional 6K bytes are needed for special EDOS job 
control enhancements. 

The core dedicated to System B can be re¬ 
turned to System A BG at any time, but first all 
System B partitions must be stopped and un¬ 
batched. A deallocation program is then run in 
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System A BG, and all the System B core, includ¬ 
ing the 2K buffer, is returned to System A BG. 

Automatic-Volume Sensing 

One of the more outstanding EDOS features as 
far as the operator is concerned is the automatic 
volume-sensing (AVS) capability. In all, there 
are three formats of AVS: assignment of direct 
devices, assignment of magnetic tape devices, 
and logical unit equivalence. 

Direct Access Device Assignment . The EDOS 
method of assigning direct access devices is a 
radical departure from the DOS procedure. With 
DOS, an absolute channel and unit address must 
be specified as well as the requirements for label 
and extent information. In addition, the operator 
must ensure that no other partition is attempting 
to reference the device. With EDOS, the absolute 
device assignment is handled by the system, us¬ 
ing the user-assigned volume serial number for 
the device. The user must only ensure that du¬ 
plicate volume numbers are not used. If this 
should happen, the system responds with a dupli¬ 
cation message. 

Magnetic Tape Assignment. One of three 
methods can be selected to specify magnetic tape 
assignments. The first requires that the volume 
serial number be designated and that no two reels 
with the same volume serial number be at the 
same load point simultaneously. 

The second method obtains a work tape or 
scratch tape. The vendor defines a work tape as 
one that is not file protected, is a load point, and 
does not contain a volume one record. A scratch 
tape, likewise, is not file protected and is at load 
point but has a volume one record. Thus, the 
second method allows the tape to be premounted. 

The third method employs a tape unit pooling 
technique. In this case an external label or op¬ 
erator-defined designator is specified in the AVS 
assign statement. The system then searches a 
common tape unit pool and, upon finding an empty 
tape unit, makes the assignment and issues the 
mount message to the operator. 

Logical Equivalence. Another good feature of 
EDOS, which should prove particularly useful in 
jobs containing multiple steps, is logical equiva¬ 
lence. With this, the user can equate a new logi¬ 
cal assignment to the same physical device as 
that of a previously assigned logical unit. In 
short, if SYS005 has been logically assigned to a 
specific printer, the statement ASSGN SYS007, 
SYS005 causes the logical unit SYS007 to assume 
the same physical assignment as SYS005. 


AVS Restrictions 

An uninitialized magnetic tape unit cannot be 
premounted. It can, however, be initialized by 
specifying an external label in the form of an as¬ 
sign statement. Upon encountering this state¬ 
ment, the system selects an unused tape drive 
from the common pool and issues a corresponding 
mount message. 

Other AVS restrictions are that neither data 
calls nor tape cartridge readers are supported 
but may be handled by way of the normal DOS 
assignment procedure. 

CPU Load Balancing 

CPU load balancing, along with relocatable 
load modules, is one of the more outstanding 
features of EDOS. 

The load balancing feature modifies the nor¬ 
mal I/O priority task dispatching scheme. When 
an I/O occurs, control is passed to a partition 
that has no I/Os in process at that time. This 
modifies the partition priority scheme so that 
normally i/O-bound jobs will run at near rated 
speeds even if higher priority partitions require 
comparatively large amounts of CPU time. The 
net effect is that system throughput is signifi¬ 
cantly increased. 

Relocatable Program Modules 

Under EDOS, the user has the option of em¬ 
ploying a slightly modified conventional DOS link¬ 
age editor or a special EDOS fast linkage editor. 
Operationally, the fast linkage editor is identical 
to its DOS counterpart but requires 44K bytes. 
Unlike the DOS linkage editor, however, the fast 
editor outputs programs in the core image library, 
which may be relocated using the EDOS relocat¬ 
able loader facility. The fast linkage editor is 
proported to be twice as fast and ideally permits 
a two to one increase in performance over the 
standard DOS linkage editor. 

Since it’s conceivable that a 44K byte partition 
will not be available to support the fast linkage 
editor, EDOS employs a determinent routine to 
check the available main storage. If sufficient 
space is not available, this routine calls in the 
modified DOS linkage editor. This editor re¬ 
quires 14K bytes and has been modified to allow 
programs to be cataloged relocatable. 

To use the relocatable loader, the user modi¬ 
fies the data on his phase card to indicate that the 
output of the linkage editor must be in a form 
suitable for relocation. He is also required to 
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specify the displacement address on this card. 

The relocatable loader in turn uses the address 
specified to determine the displacement within 
the partition and catalogs the phase/relocatable 
entries. The system also builds a phase relocat¬ 
able list dictionary, showing phase names that 
are identical to program names. 

Catalog Procedures 

Cataloging of JCL statements under a unique 
name in the source statement library is another 
notable EDOS feature. In operation, procedures 
are cataloged to the source statement library with 
the standard IBM maintenance program in the 
same manner as any other source statement li¬ 
brary book. The maintenance program is also 
used to modify or alter statements previously 
cataloged. 

The difference in the EDOS technique is that 
each set of job control statements is then known 
as a procedure and is referred to by its unique 
procedure name. 

Note that cataloging of job control statements 
can be done on DOS by specifying such statements 
as SYSIN. However, these statements are merely 
a continuous stream of card images; there is 
no selectivity within the procedure. 

The EDOS "macro language” facility permits 
selective statement retrieval or use based on 
UPSI (User Program Sense Indicator) settings, 
SYSPARM option, or the completion code of the 
previous step. 

Job Accounting Support 

EDOS job accounting support programs con¬ 
sist of three programs: Two swap and dump the 
accounting area, and the third produces a sum¬ 
mary report program. Standard DOS job control 
accounting exits are used to capture complete ac¬ 
counting data for each job step. 

The swap program, called AR/SWAP, runs as 
a standard problem program in any partition and 
essentially clears the accounting area (using 
standard DOS routines) and signals that the area 
should be used to record any new accounting data. 
The cleared data is stored on disc. 

The dump program, called AR/DUMP, also 
runs as a problem program in any partition and 
is executed after AR/SWAP. AR/DUMP copies 
the accounting data from the disc to a magnetic 
tape and can be used to periodically collect ac¬ 
counting data until the end of the accounting pe¬ 
riod. With conventional DOS, the actions per¬ 
formed by SWAP and DUMP must be done by 
user-written programs. 


The summary report program sorts the 
detailed job step accounting data (produced by 
AR/DUMP) by date, partition, and start time se¬ 
quence, then prints summary reports. If de¬ 
sired, the system can produce a magnetic tape 
that contains summarized data for all steps of 
each job. A report file can be written, and one 
of three levels of detail selected. 

The job accounting support feature also pro¬ 
vides hooks for user-written data validation rou¬ 
tines, which can be invoked to verify accounting 
data prior to recording it on the accounting file. 

Resident Transient Routines 

Under EDOS, frequently called logical tran¬ 
sient routines can be link edited to relevant pro¬ 
grams during the normal link editing process. 

The significance of this feature as it relates to 
seek and fetch time saved is quite pronounced, 
especially when programs require indexed se¬ 
quential processing. However, the feature does 
require additional core. The additional amount 
is determined by the actual size of the transients 
linked with the program. 

Utility Programs 

Four notable utility programs are offered by 
EDOS. The first, called Compile, is executed 
instead of the language processor and extends the 
source statement library to all compilers. It op¬ 
tionally provides automatic auxiliary backup to all 
source programs. 

Primary input to Compile is read from 
SYSIPT, which can be a card reader, magnetic 
tape, or disc extent. The primary output is a 
magnetic tape used as a SYSIN file. Before run¬ 
ning Compile, the user must specify the com¬ 
piler to be used. Valid operands are Assembly, 
Cobol, Cobol F, Fortran, Fortran F, PL/1, 

RPG and RPG II. 

When executed, Compile creates the SYSIN 
tape, which is used to perform the actual compi¬ 
lation. If backup is specified, the source state¬ 
ments are saved on a disc extent, which can be 
accessed and updated simultaneously from any of 
the six partitions. These statements are later 
transferred to magnetic tape. 

The second utility, called Volume Dump, pro¬ 
vides a magnetic tape backup for the Model 2314 
or 2311 Disk. Although it will execute in as lit¬ 
tle as 44K bytes, its performance improves con¬ 
siderably as more core is allocated (up to 200K 
bytes). Other factors affecting performance are 
magnetic tape speed, disc data format, and 
whether single or separate channels are used for 
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tape or disc. Under optimum conditions, the 
vendor claims the entire contents of a 2314 can 
be transferred to magnetic tape in approximately 
4 minutes. 

A third utility, called Volume Restore, is 
used to restore a disc pack dumped by the Vol¬ 
ume Dump program. It also requires 44K bytes 
of main core, but no performance improvement 
occurs with provision of additional core. 

The final utility, called Document, reproduces 
EDOS documentation either in whole or by se¬ 
lected sections. Document is a three-pass pro¬ 
gram. The first pass copies requested data to 
disc; the second pass formats the text and prints 
the table of contents; and the third pass sorts and 
prints the cross-reference index. 

In addition, since Document is actually a text 
editing program, it can be used to service user 
documents. 

Recent Enhancements 

EDOS has received a number of enhancements 
since its inception, among them being an I/O 
spooling capability and a 360/370 compatibility 
feature. 

I/O Spooling . The spooler was badly needed, 
for without it the multiprogramming benefits de¬ 
rived from 6 partitions could not be fully real¬ 
ized. In our original report on EDOS (April, 

1972) we faulted the vendor for omitting this 
feature. 

The EDOS spooler was announced in January, 
1973. Unlike most spooling programs, this one 
is integrated into the EDOS nucleus, adding 2K 
bytes to the area above supervisor. The spooler 
itself is brought up at IPL time. If a user 
chooses not to employ this feature, the SVC’s are 
handled by the standard DOS routines. Please 
note that if the EDOS spooler is not used, the 2K 
bytes reserved for it is carried as overhead. 

The technique employed by the EDOS spooler 
differs radically from its chief competitor’s (for 
example, Grasp, Sprint, and so forth) in that 
simulation models are employed to handle virtual 
devices. The user assigns these virtual devices 
through JCL, and the simulation modules are 
dynamically loaded. For each device type speci¬ 
fied, 2K bytes must be reserved in one partition 
of main storage. 

Overall, this method of handling devices ap¬ 
pears to be a good one, if only from an overhead 
viewpoint. For by being able to select only what 


you need and retain it for only as long as you 
need it, unnecessary core dedication is 
eliminated. 

Other notable features of this spooler are 
complete record compression (normal) or user- 
specified record transaction, shared buffer area, 
generic queues, automatic warm restart, full 
I/O accounting, and built-in remote job entry 
(RJE). The latter feature, and extra cost option, 
was incorporated in late 1973 and removed one 
of the system soft spots we pointed out in an 
earlier report. 

The RJE facility is an integrated system fea¬ 
ture, requiring 12 to 16K bytes for its control 
module plus a 4K module for each device type. 

It supports both high and low speed devices; 
gives remote users access to EDOS procedure 
labraries and automatic volume sensing; and 
provides sign-on security. A unique forms con¬ 
trol procedure allows the remote user to indi¬ 
cate which form is to be mounted; the system 
then automatically selects reports from the out¬ 
put queue requiring that form. 

360/370 Compatibility . With the optional 
360/370 compatibility feature, the full 370 in¬ 
struction set can be used with negligible system 
degradation — according to the vendor. System/ 
370 users can also employ this feature to use a 
360 as a backup machine. 

Effectively, this feature permits programs 
containing the 370 instruction set to be executed 
on a 360. When DOS signals that a non-360 in¬ 
struction has been encountered and issues a pro¬ 
gram check, the cause of the program check is 
examined. If caused by a 370 instruction, that 
program check is ignored and control is passed 
to a simulation routine to ’’execute” the instruc¬ 
tion; if the program check was caused by any 
other means, it is dispatched according to nor¬ 
mal DOS procedures. 

Extended Features 

A forthcoming release (Release 5.1) to EDOS 
will offer seven enhancements: 

• System Transient Optimizer — allows auto¬ 
matic creation of a system transient load 
list. 

• Asynchronous UCS — permits mid-execu¬ 
tion loading of the UCS buffer to ensure 
continuous printer operation. 

• Cataloged Reader Data Sets — permits in¬ 
dependent data cataloging on private or sys¬ 
tem libraries. 
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• Library Optimization Program — reorga¬ 
nizes the core image library to optimize 
performance. 

• Selective ESF Tape Utility — selectively 
blocks (on tape) spooled data sets. 

• Permanent Job Queues — permits optional 
reexecution of jobs without resubmission. 

• Release 6, which will contain the 370 DOS 
Release 27 oriented enhancements (includ¬ 
ing 3330 support), is projected for late this 
year or early next. 

We wonder when the DAT box is coming? 
Evaluation 

EDOS, unquestionably, offers System/360 DOS 
users a convenient way out of the hassle of either 
switching to OS/360 (and thus suffering the trep¬ 
idations of a DOS to OS conversion) or com¬ 
pletely switching to 370 DOS/VS. 

The EDOS facilities are indeed impressive. 
With load balancing, automatic volume recogni¬ 
tion, relocatable program modules, six-partition 
support, and spooling, it combines the best fea¬ 
tures of many independently marketed products. 
The cost is also quite reasonable, too. 

However the proof of any package is in the 
running and in the opinions of its users. Does 
EDOS live up to its claims? For the most part, 
it certainly does. 

The users we interviewed were running either 
four or five active partitions and were extremely 
well satisfied with EDOS and the support ren¬ 


dered by the vendor. The few small problems 
encountered were fixed immediately, and the 
vendor has shown continuing interest in the pro¬ 
duct and user related problems. That says a 
whole lot for the vendor. 

But, despite all its commendable features, 
EDOS still has a few soft areas which may or 
may not prove troublesome, depending upon your 
needs. 

The load balancing features, paradoxically, 
can also get you into trouble if you do good job bal¬ 
ancing the I/O and compute portions of your pro¬ 
gram. Because of the way I/Os are handled, an 
intelligently written program could monopolize 
the CPU and shut out the other partitions. 

There are a few ways around this. You could 
tell your programmers to write sloppy code and 
get yourself fired, or you could run the M CPU 
eater” at a nonpeak period. If neither solution is 
acceptable, you could take out the double buffer¬ 
ing feature of EDOS, and that should eliminate 
the problem. Now it could be argued that since 
a well balanced program will shut out the other 
partitions under standard DOS, why rap EDOS? 
Well, EDOS runs six partitions, four of which 
are foreground. 

Also since EDOS has profited by correcting 
many DOS shortcomings, why not correct one 
more: no time slicing capability. That feature 
would definitely move EDOS into the big league 
of multiprogramming operating systems. 

HEADQUARTERS 

The Computer Software Company 

7th & Franklin Building 

Richmond VA 23219 
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GENERAL 

The Control Data Multiple Access Shared Time 
Executive Routine (MASTER) is a large-scale^ 
mass storage-oriented (disc or drum) operating 
system for Control Data 3170, 3300, and 3500 
computer systems. It handles applications in¬ 
volving multiaccess on-line I/O operations con¬ 
current with real-time and conventional batch 
processing, and also supports conventional batch 
processing applications and limited remote time¬ 
sharing capabilities. 

The Master system utilizes the dynamic relo¬ 
cation and protection features of the optional 3311 
Multiprogramming Module to permit seven user 
programs to process concurrently in up to262,144 
(24 bits) words of core storage. A maximum of 
131,072 words of core storage is allowed in sys¬ 
tems without the multiprogramming module. 

Multiprogramming is one of the principal fea¬ 
tures of the CDC 3300/3500 systems, accommo¬ 
dating (under Master) up to 8 program address 
groups (called "states"), each of which can con¬ 
tain an independent program. The resident op¬ 
erating system routines require 16K words of 
core and occupy 1 program state, leaving 7 
states for user programs. 

Master segments the programs into pages 
which fit into these states. Each state in turn is 
divided into 16 pages each of which contains 2,048 
words. The smallest allocatable portion is one- 
quarter page, or 512 words. The system main¬ 
tains 16 page indexes to facilitate relative ad¬ 
dressing and program relocation during execu¬ 
tion of a task, and to permit and/or inhibit read¬ 
ing and writing in the indexed pages. Due to the 
addressing scheme, only 128 pages can be ad¬ 
dressed directly. 

Job Handling 

Jobs are queued and executed in accordance 
with programmer designated priorities. The 
programmer may also submit such parameters 
as estimated core requirements, run time, and 
necessary peripherals. If he fails to assign a 
priority or supply the estimates, the system does 
it automatically. 

Five priority designators are recognized by 
the system; from the highest to lowest they are 
emergency, background, special, I/O, and com¬ 
pute. Special jobs are I/O or compute bound 
programs which have been reclassified by the op¬ 
erating system to provide fast turnaround time. 

Such reclassification is made on the basis of 
their estimated run time. 


Ordinarily, jobs are queued and scheduled by 
class, and at all times the system attempts to 
keep at least 1 job active from each class. The 
latter procedure is quite a digression from the 
way most operating systems handle job schedul- 
ing, in that under the others, lower priority 
(class) jobs must wait for all higher priority jobs 
to be executed before they are scheduled. Under 
Master, multiple jobs from the same class are 
initiated only when scheduled jobs from other 
classes cannot be initiated. 


Within a class, jobs are usually initiated on 
a first-in, first-out basis provided sufficient I/O 
resources and main core are available to allow 
them to run to completion. All resources are 
dynamically allocated. If the required resources 
are unavailable, the job retains its position in the 
queue and the next job is examined for selection. 


There are 2 exceptions to the scheduling and 
selecting rule, namely, emergency jobs and 
force-scheduled jobs. Emergency jobs, like all 
jobs under Master’s control, must have all the 
necessary I/O resources available before they’re 
selected. They needn’t, however, have total 
core requirements available to begin execution; 
rather, they may begin with a minimal amount 
of core and Master will assign additional core as 
it’s released by other jobs. 

A job is force-scheduled when the number of 
times it is passed over for scheduling (due to 
insufficient resources) reaches a limit prespec¬ 
ified by the user. When this condition occurs, 
no other nonemergency job may be initiated until 
the waiting job receives its resources and is 
entered. 


Master also contains a facility which permits 
several user-written, real-time routines to be 
linked into the system executive. These routines 
are called via a real-time interrupt recognized 
by the supervisor. 


Master does impose a restriction on serially 
dependent jobs. If the output from one job is re¬ 
quired before a second job can proceed, the sec¬ 
ond job must not be submitted to the system be¬ 
fore the first has reached completion. There is 
no way in which the two jobs can be linked so that 
one will wait for the other. Some serially depen¬ 
dent jobs can be made serial tasks of the same 
job so that the system will not time-share them. 

In the example, task B which uses the output from 
task A will not be initiated until task A has been 
completed. 
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Task Executive 

In a multiprogramming environment, a pro¬ 
grammer can segment a job into tasks to accom¬ 
plish parallel execution of several tasks. Mas¬ 
ter maintains a list of program tasks to be per¬ 
formed. This list includes the priority of each 
task and other information required by the oper¬ 
ating system for supervising the task. Tasks 
are executed according to priority and to the 
availability of core storage and peripheral 
devices. 

Executing tasks can also request the execution 
of other tasks by issuing a call for those tasks. 
The calling task always remains suspended until 
the call is completed. If the parameters of the 
call permit, the calling task may be multipro- 
grammed with the called task, or it may wait for 
the task to be completed before resuming 
execution. 

Once a task begins executing, a timer is set 
to force an interrupt. The time limit is the min¬ 
imum of: the allocated time remaining for the 
job, the time specified in a limit request, or the 
time for an execution cycle (the maximum time 
a task is allowed to be executed without interrup¬ 
tion). When a time interrupt occurs, it is pro¬ 
cessed to determine which time expired. If it is 
the job or limit time, the job is terminated. If 
it is the execution cycle time, the system places 
the next highest priority task in execution. Ex¬ 
ecution cycle time is an installation parameter 
that prevents any one task from occupying the 
CPU indefinitely. Generally, a timer interrupt 
occurs every 100 milliseconds. 

As a job is processing, all output data is 
spooled to mass storage. When a job completes 
processing, Master closes all open files related 
to the job and releases all scratch files, input 
files, core storage, and any scheduled devices. 
An output postprocessor then extracts the spooled 
output data and handles its outputting to printers 
and punches. 

Remote Terminal Support 

Support in this area is not through Master di¬ 
rectly, but is attainable via 3 separate subsys¬ 
tems: Export/Import, Respond, and MCS3. Ex¬ 
port/Import allows jobs to be submitted from re¬ 
mote card readers to the system batch process¬ 
ing job stack, and to receive output at remote 
sites. 

Respond is a multiaccess subsystem which 
allows users at terminals to create and main¬ 
tains files, and submit files as jobs for batch 


processing. It can service up to 10 terminals 
and requires 48K words of core. 

The MCS3 subsystem is a message switcher 
which queues incoming and outgoing messages. 
Although it will work with Export/Import, it ap¬ 
pears to be intended primarily to handle mes¬ 
sages coming from or going to remote terminals, 
Teletypes and CRTs. Cobol and Fortran inter¬ 
faces are provided for the Message Control 
System. 

Configuration Requirements 

The minimum configuration for Master in¬ 
cludes a 3304 or 3500 central processor with at 
least 32,768 words of core storage and the op¬ 
tional 3311 Multiprogramming Module; a 405 
Card Reader, a 501 or 505 Line Printer, and a 
415 Card Punch, each with a buffered controller; 
and 2.5 million words of mass storage, which 
can be composed of any combination of Models 
813, 814, 852, 853, or 854, 841, 813, 821, 844 
Disk Files or Model 863 Drum Storage Units. 

Between 4 and 8 magnetic tape units should be 
used in order to optimize the performance of 
Master. In addition, Master controls the use of 
1 card reader, printer, and card punch for 
processing input and output files. A user re¬ 
quiring direct use of these peripheral devices 
may include additional units in the configuration. 

Control Data 3170, 3300, and 3500 computer 
systems operating under Master can include up 
to 8 data channels, additional I/O equipment, 
multiple central processing units, on-line remote 
terminals, and up to 262,144 words of core 
storage. 

LANGUAGE SUPPORT 

Programming languages supported by Master 
consist of Fortran, Algol, Cobol, and ANSI For¬ 
tran and Cobol. Assembly languages program¬ 
ming is provided via a Meta assembler. 

FUNCTIONAL CHARACTERISTICS 

Job Types 

Batch and limited time sharing. 

Job Scheduling 

Job class; passover limit. 

Resource Allocation 

Main Storage: statistically assigned, fixed 
size regions. 
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CPU Time: indefinite time period. 

I/O Devices: dynamically assigned. 

Informative Files: dynamically assigned; 
shareable and nonshareable programs and sub¬ 
routines permitted. 

Program Structure and Loading 

Individual pages divided into quarter pages of 
512 (24-bit) words each. Page addressing em¬ 
ploys a 15-bit address scheme, for example, 
three-bit address of the core storage area is com¬ 
bined with upper four bits of the standard 15-bit ad¬ 
dress to produce the seven-bit addressing scheme. 
Up to 128 pages can be addressed directly. 

I/O Control 

Device Type: disc, magnetic tape, drums, 
typewriter, unit record devices. 

Buffer Allocation: single, double, and 
exchange. 

Remote Terminal Support: remote batch pro¬ 
cessing; standard terminal speed and format. 

Recovery Processing 

Checkpoint all jobs; restart from beginning of 
job; no roll-out, roll-in; print and punch files re¬ 
started from first line or card. 

Diagnostic Error Processing 

Hardware, software, and interface errors 
recognized. All errors result in an error mes¬ 
sage. Recoverable errors (usually minor) han¬ 
dled automatically by system routines; unrecov¬ 
erable errors handled by user. 

Processing Support 

Timing Services: internal and real-time. 

Testing and Debugging: snapshot and post¬ 
mortem dumps only. 

Logging and Accounting 

Standard accounting data and hardware error 
statistics kept. 

File Management 

Data stored and retrieved on logical record 
level only; cataloging is dynamic. User and sys¬ 
tem labels identify files. 


File Structure 

Sequential and indexed. 

File Storage Allocation 

Auxiliary storage size and density defined by 
user; storage assigned dynamically. 

File Location 

File name and/or user defined password (to 
file name only) using master catalog. 

File Access Methods 

Sequential, indexed (optional), and random. 
Job Control Language 

Inconsistent mixture of verb-oriented and 
parameter-oriented control cards, mostly para¬ 
meter-oriented. Incorporates common utility 
functions and services as well as environment 
control and data definition. Consists of the fol¬ 
lowing four classes: 

• Schedulers and environment control: DI¬ 
RECT and SCHED control spooling capa¬ 
bilities, projected resource utilization, and 
task priorities. 

• Job and task relationships: JOB and TASK 
along with taskname cards control the re¬ 
lationship of tasks within jobs and the 
necessary identifying information for 
multitasking. 

• File specification: FILE, XFER, and 
others control user file specifications at 
a symbolic level. 

• Compiler calls, program modification, 
and debug facilities. 

Sorting and Merging 

No sort and merge routines are incorporated 
into Master itself. Control Data, however, offers 
a number of such routines for use with the 3300/ 
3500, the most popular being the Mass Storage 
Sort. 

Mass Storage Sort is a multipurpose sorting 
program which allows sort only, sort and merge, 
or merge only operations. Input can consist of 
fixed or variable length, blocked or unblocked 
records. Records are stored according to any 
specified collating sequence in ascending or de¬ 
scending order. 
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Modification programs allow operations such 
as deletion, insertion, summarization, record 
size or content changes, nonstandard label check¬ 
ing and modification, generation of operator 
messages, and job termination. These previ¬ 
ously assembled user-written subprograms are 
in relocatable binary form on the standard or 
some other specified unit, and are indicated by 
control cards. 

Disc files are manipulated by the Mass Stor¬ 
age Input/Output (MSIO) program and must fol¬ 
low MSIO labeling conventions. However, if tape 
input or output is elected, the tape file may be 
unlabeled or contain standard or nonstandard 
header and trailer labels. 

Mass Storage Sort operates with 2 Model 852 
Disks, 16K of memory, standard input (card 
reader or tape), standard output (printer or 
tape), and a console typewriter. Only full rec¬ 
ord sorting is performed. 

The sorting process is directed by data fields 
called sequencing keys. These keys contain the 
values of one or more data fields within a record, 
and govern the rearrangement of files in the 
sorting process. 

CDC also provides tag and tape sort programs 
for use under Master. 

DESCRIPTION AND EVALUATION 

Master is one of those operating systems that 
has come a long way, but still has some distance 
to travel. 

Its system support features, for example, 
were noticeably weak in that no hardware error 
statistics were kept to show which components 
were going soft. This has been fixed. 

Still missing, however, is a solid checkpoint/ 
restart capability. When the system crashes, 
the operator must still reinitiate the entire step. 

Overall, Master is fairly competent and is 
not too terribly hard to use. This doesn’t mean 
the operator can fall asleep, or the programmer 
can be totally lax when planning his jobs. But 
it doesn’t require total vigilance by one and com¬ 
plete intimacy by the other, either. 

The following paragraphs highlight some of 
the more noticeable features of Master. 

Job Scheduling 

In some ways, the scheduling techniques em¬ 
ployed by Master are quite similar to those used 


by OS/360 and 370. Both schedule jobs by class, 
and both permit the processing time slice to be 
varied in accordance with the job’s priority class. 
(Excellent features, in our opinion.) 

Unlike OS/360, Master normally requires all 
system resources to be available to allow the job 
to run to completion before it’s selected for pro¬ 
cessing. * Until such resources are available, 
the job remains in the input queue. With OS/360, 
on the other hand, the job begins processing as 
soon as enough resources are available to allow 
it to do so. No provision, however, is made to 
ensure that enough resources will be available 
to allow the job to finish. This can result in re¬ 
duced throughput overall, since a waiting job re¬ 
tains its unreleased assigned resources. 

It is better, we feel, to have a job wait in its 
queue until all the resources it needs are avail¬ 
able, as Master does. 

To ensure that jobs are not passed over indef¬ 
initely, 2 scheduling provisions have been made 
by Master: emergency scheduling and forced 
scheduling. Emergency scheduling is the highest 
assignable priority, and requires a job to have 
all the necessary I/O resources available before 
it’s selected. It needn’t however have sufficient 
core; it may begin with minimum core and the 
system assigns additional core as it becomes 
available. 

With forced scheduling the user specifies, as 
a system option, the number of times a job can 
be passed over before it must be scheduled. 

When this limit is reached, no other nonemer¬ 
gency job takes precedence. (This technique is 
similar to the Exec 8 start-time/deadline 
procedure.) 

Another departure from OS/360 — and most 
other operating systems for that matter — is the 
way jobs are selected for processing. If no 
pass-over limit is indicated, the jobs are stacked 
in their respective queues based on priority and 
serviced first-in, first-out based on the avail¬ 
ability of resources. No numeric weighting of 
jobs is used. Also, Master ordinarily does not 
follow the usual procedure of servicing all high 
priority jobs first, leaving the lower jobs 
’’stalled” in their queues. Rather, the system 
attempts to keep at least 1 job from each queue 
active at all times. The exception, of course, is 
when a number of jobs reach their pass-over lim¬ 
its or when a number of emergency jobs are en¬ 
tered simultaneously. 


* Only emergency jobs may begin processing 
without all resources being available. 
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Another factor influencing whether a job is 
scheduled is the programmer’s estimate of the 
job’s working set. This is discussed later under 
Memory Allocation . 

Resource Allocation 

Like most advanced operating systems, Mas¬ 
ter employs dynamic allocation to mete out re¬ 
sources. However the method it uses to handle 
paged programs and memory is notable, in light 
of the new interest in virtual memory wrought by 
IBM’s embracing of that concept. 

Memory Allocation Master employs the 
paged concept, whereby individual pages can be 
divided into 4 quarter pages of 512 memory loca¬ 
tions each. Programs can have full, three-quar¬ 
ter, one-half, or one-quarter pages of memory 
allocated to them. When a program is to be 
loaded, one of Master’s loaders (relocatable or 
absolute) loads the task into available pages of 
physical memory, where it remains until the job 
or operating system releases this allocated core. 

The memory allocator allocates memory to 
the loaders on a page basis as a task is being 
loaded. Each time a task is placed into execu¬ 
tion, its page map is written into 1 of the 8 areas 
of the page index file so that the physical page 
assignments are available to the hardware. 

Memory for common core is assigned on a 
one-quarter page basis after the entire task has 
been loaded and the memory assigned to the 
loader has been released. Thus this portion of 
memory is frequently used for the common area. 

During loading, the loader generates either 1 
page map for the program-data and common 
area, or 2 separate maps for the task’s pro¬ 
gram-data and common areas. (A task with sep¬ 
arate page maps for program and common areas 
is called a 2-chapter task. *) 

The actual allocation of storage is performed 
dynamically during loading. However, before 
such loading begins, the system notes the pro¬ 
grammer’s estimate of the maximum amount of 
storage to be used by all tasks that will reside 
simultaneously in core. A job is not permitted an 
internal storage allocation in excess of its esti¬ 
mate. If such a request occurs, the job is ter¬ 
minated abnormally. 

Another factor influencing whether a job is 
scheduled is the programmer’s estimate of the 


* To simplify addressing for the user, memory 
is represented as 2 blocks, each with 32K con¬ 
secutive logical addresses, called chapters. 


job's working set. The working set is a collec¬ 
tion of frequently called pages. If the estimate 
is too high, the job is not scheduled; if it’s lower 
than what is actually needed, the system enters 
a condition called ’’thrashing,” that is, the sys¬ 
tem spends so much time fetching and throwing 
pages that it is unable to perform productive 
work. When thrashing begins, the job is termi¬ 
nated abnormally. 

Obviously, the programmer’s estimate of the 
working set is quite critical, perhaps too critical. 
It would be better, we feel, to remove the man 
from this cycle, and leave working set determi¬ 
nation up to the system. 

Master also provides facilities which allow in¬ 
ternal storage to be shared by 2 or more tasks of 
the same job. Such core is called ’’common stor¬ 
age” and may not be preloaded. Common stor¬ 
age is not assigned physical memory until the 
task is actually established. During execution, 
the task can assign or release core as its needs 
change. 

I/O Facilities 

I/O facilities are allocated automatically, and 
consist of I/O stream devices, unit record de¬ 
vices (including magnetic tape), and mass stor¬ 
age files. Each job is allocated an input stream 
and 2 output stream files upon initiation. All 
other peripheral equipment, except displays and 
Teletypes, required by a job must be scheduled 
prior to job initiation. Unit record devices are 
assigned from a pool maintained for each device 
type by the stream. 

Mass storage may be in the form of either 
permanent files or scratch files. The number 
of segments needed for a scratch file is specified 
on an input control card. Space on the scratch 
file is allocated dynamically during task execu¬ 
tion and can not exceed the amount specified by 
this parameter. 

Permanent data files are allocated on dynamic 
basis and need not be scheduled via an input con¬ 
trol card. In addition, they may be shared 
among any number of tasks. Should a task at¬ 
tempt to access a file being used by another task, 
the access request is queued and the task is 
temporarily suspended until the using task com¬ 
pletes its I/O activities. When the access re¬ 
quest is dequeued and initiated, the suspended 
task is resumed. 

HEADQUARTERS 

Control Data 

P. O. Box O 

Minneapolis, MN 55440 
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OVERVIEW 

Control Data's 6400, 6500, and 6600 operating 
system, Scope, is a comprehensive control system 
designed to coordinate the parallel and indepen¬ 
dent operations of the multiprocessing, multi¬ 
programming 6000 Series systems. This report 
describes the features of Scope Version 3.3. 

SCOPE is the official 6000 Series operating 
system, designed to replace the earlier SEPROS 
and CHIPPEWA operating systems. It provides 
the control routines necessary to supervise the 
execution of many main programs or program 
segments residing in central memory and the 
concurrent execution of independently functioning 
programs in each of the system’s 10 peripheral 
processors. The standard version of Scope con¬ 
trols stacked-job processing of a large number 
of programs scheduled on the system disc. 

Of the 10 peripheral processors, one is 
assigned to the monitor program; one is allo¬ 
cated to handle display programs; and one is 
reserved to handle l/O requests to discs. The 
remaining seven are held in a common pool and 
assigned to jobs as needed. 

Scope’s major objective is to handle dynam¬ 
ically changing situations in which many jobs are 
being processed concurrently, with I/O opera¬ 
tions, computations, compilations, and system 
and program testing operations simultaneously 
active. The system constantly evaluates the 
status of all its parts and attempts to maximize 
the use of each component, especially the cen¬ 
tral processor and peripheral processors. Thus, 
processing and I/O optimization procedures are 
performed automatically, without extensive pre¬ 
planning by the programmer or system operator. 

’’Continuous mode” operation of relatively 
slow output devices (card punch, printer, plotter) 
is provided by storing the output data of a 
particular job on disc storage until the job is 
complete and then performing the output opera¬ 
tion. Input data from low-speed devices can 
similarly be buffered by storing a job’s total 
input on intermediate disc storage. 

Principal Programs 

The principal Scope programs are an execu¬ 
tive, a monitor, a job loader, several file main¬ 
tenance routines, and a display routine. Both the 
executive and monitor routines share the use of a 
dedicated peripheral processor, while the system 
display program is assigned to another peripher¬ 
al processor. (The other eight peripheral pro¬ 
cessors have no fixed assignments but form a 


pool available for any Scope assignment.) The 
central resident program resides in central mem¬ 
ory and contains the system tables and pointers, 
the communication areas for linkage between the 
peripheral and central processor memories, and 
the most frequently used subroutines. All other 
portions of Scope reside on disc and can be called 
as needed, by the monitor. 

Scope imposes no demands upon the central 
processor, which can therefore devote most of its 
time to processing user programs. The periph¬ 
eral processors perform all the Scope control 
functions; and the central memory accesses re¬ 
quired for Scope operations can be completely 
overlapped with central memory accesses by the 
central processor, which is given priority when¬ 
ever there are conflicting requests for access to 
a particular memory bank. 

Executive . The executive schedules and super¬ 
vises the concurrent operations of the central 
processor, the peripheral processors, the 12 I/O 
channels, and the peripheral equipment (except 
for disc file units). Assignments are made ac¬ 
cording to equipment availability. (Operator- 
defined I/O assignment is also possible.) 

In addition, the executive maintains a status 
list for each active job in the system, whether 
currently in central memory or stacked in the 
system disc. The executive continuously exam¬ 
ines these status lists and initiates appropriate 
action upon detecting status changes. 

The standard environment in which Scope func¬ 
tions consists of many programs concurrently re¬ 
siding in central memory, with each program 
periodically receiving processing control. Simul¬ 
taneously, the 10 peripheral processors can be 
performing other independent tasks (both system 
control functions and jobs assigned by the execu¬ 
tive) either in support of central processor pro¬ 
grams or as independent off-line operations (such 
as data transcriptions). 

A comprehensive priority system determines 
the order in which Scope assigns equipment to the 
jobs in central memory and initiates their execu¬ 
tion. Priorities can be assigned by the program¬ 
mer, by the operator, or by the system; and 
different priorities can be assigned to the pro¬ 
gram’s main processing and its I/O operations. 

Priorities can also be designated as changing 
or fixed: Changing priorities are modified peri¬ 
odically by Scope to ensure that lower-priority 
programs receive a proportionate amount of pro¬ 
cessing time and are not ignored due to insistent 
demands of higher-priority programs with which 
the less important jobs may coexist. A central 
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processor program currently being processed 
loses control whenever it encounters a program 
wait, such as a wait for completion of an I/O 
operation. 

Jobs in execution are assigned control points 
(that is, dynamically changing memory partitions) 
according to the field length requirements de¬ 
clared on the job card. Each job consists of one 
or more programs preceded by job control cards 
that specify the name of the job, its priority 
level, a time limit, the memory requirements, 
and the type of operations to be performed on the 
job file records. 

If the new job does not disturb the other con¬ 
trol points, no program relocation takes place. 
However, if the job requires more storage than 
is available at the control point, then memory 
orientation facilitates interruptions, allowing 
jobs to remain in a ready state at reentry time. 

Monitor . The monitor works in conjunction 
with the executive, continuously checking the 
progress of the program in central memory that 
is being executed by the central processor. Any 
need for action, such as an I/O request, is re¬ 
layed to the executive for initiation of appropri¬ 
ate action. As the monitor cycles through its 
list of jobs and finds wait conditions, it switches 
control to the next eligible job in priority 
sequence. 

Each peripheral processor (PP) has 4, 096 
words of memory and an assigned communica¬ 
tion area in central memory containing an input 
and output register and a message buffer. The 
monitor interfaces with the PP by putting a con¬ 
trol word in the input register when the operation 
is assigned. The PP obeys the order, indicates 
in the output register when the operation has 
been completed, and returns to an idling state in 
which it continually interrogates its input regis¬ 
ter for the next order. In turn, the monitor 
periodically reads the output register for opera¬ 
tion completion and for requests from the PPs 
for access to I/O channels and other tasks to be 
scheduled by the monitor. Thus, the communi¬ 
cations registers permit the monitor to direct 
all PP activity. 

Job Loader . The job loader routine provides 
access to a complete library of system and prob¬ 
lem programs stored on the system disc. It is 
called whenever the executive determines that 
sufficient space in central memory and suffi¬ 
cient peripheral equipment are available for 
additional jobs that are stacked in the system 
disc. The job loader then transfers the execu¬ 
tive-selected programs from the system disc to 
central memory and sets the status of the suc¬ 


cessfully loaded programs to ’’waiting.” Control 
passes to the newly loaded programs. 

In addition to the loading function, the loader 
can link separately compiled or assembled pro¬ 
grams, as well as library and user programs. It 
can detect errors and generate diagnostics or an 
entire memory map. 

File Maintenance Routines . Two file process¬ 
ing utility routines, EDITSYM and UPDATE, 
perform the primary file maintenance function. 

The EDITSYM routine processes symbolic card 
decks in compressed form. The routine handles 
sequencing and can both create and modify pro¬ 
gram libraries either independently or concur¬ 
rently. The UPDATE routine creates the system 
library file, which resides on disc, in central 
memory or on a dead-start load tape. It oper¬ 
ates in a normal multiprocessing environment 
and is submitted as any other job. It can update 
the system library and change the residence of 
the library routines. 

In addition, copy utility routines are available 
to create and check labels for magnetic tape files, 
prepare job input tapes, format print files, and 
copy records from one file to another. 

Display Routine . The display routine provides 
operator monitoring information and central mem¬ 
ory displays on two console screens. Storage 
displays can be used for storage manipulation to 
facilitate program testing and diagnostic proce¬ 
dures. By entering memory modification and 
system requests through the console keyboard, 
the operator can override Scope standard instal¬ 
lation conventions and parameters to modify job 
priorities, introduce new jobs, delete active jobs, 
remove specified I/O devices from available 
status, and so forth. 

LANGUAGE SUPPORT 

Programming languages that SCOPE supports 
include Compass (assembly language), Fortran, 
Extended Fortran, Algol, and Basic. 

OPERATING ENVIRONMENT 

Minimum configuration for running SCOPE is 
a basic 6000 Series system, including a central 
processor, at least 32K 60-bit words of central 
memory, 10 peripheral and control processors, 
and 12 i/o data channels. Peripheral devices 
must include a console display device, sufficient 
rotating mass storage space (6603, 6638, or 841), 
two 607 Tape Units, a card reader a card punch, 
and a line printer. Dedicated facilities consist 
of two peripheral and control processors, plus an 
unspecified amount of system disc storage. 
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Any extra facilities desired can be used to ex¬ 
pand the minimum configuration. Control cards 
or keyboard entries are used to inform Scope of 
changes in equipment availability. 

FUNCTIONAL CHARACTERISTICS 

Job Types 

Batch (std); interactive and remote batch 
(optional). 

Job Scheduling 

Numeric priority; jobs service first in, first 
out (FIFO) intraqueue and round-robin interqueue. 

Resource Allocation 

Main storage: user specified, variable size 
regions. 

CPU time: 64-millisecond time slices. 

I/O devices: dynamically assigned and reas¬ 
signed; devices can be dedicated to a job or 
shared. 

Information files: statically assigned or 
dynamically allocated; read/write-only access; 
nonreusable, serially reusable, and reentrant 
files permitted. 

Program Structure and Loading 

Simple, planned overlay, and dynamic struc¬ 
tures (see Program Loading). 

I/O Control 

Programmer requests buffer or are dynam¬ 
ically assigned. 

Remote Terminal 

Mixed line speeds; both interactive and remote 
batch supported. 

Recovery Processing 

Checkpoint/re start all jobs; user restart from 
beginning of job or from a job step. Restart by 
card. Tapes and discs restored to position be¬ 
fore checkpoint. 

Error Diagnostics 

Hardware and program errors recognized; 
diagnostic routines provided; errors retried. 


Testing and Debugging 

Program, snapshot, and label dumps; trace 
routines provided. 

Timing Services 

Interval clock only; no real-time services. 

Logging and Accounting 

A chronological dayfile is used as the reposi¬ 
tory for logged data and provides the source data 
for the accounting routines. It contains a running 
account of all control cards, equipment assign¬ 
ments, error diagnostics, central and peripheral 
processor time used, and I/O routines used by 
jobs. At the end of a job, its statistics as main¬ 
tained in the dayfile are printed out. 

File Management 

Catalogs of private files permitted (but no form 
of security provided); both system and user labels 
permitted. 

File Structures 

Hierarchical structures permitted. 

File Storage Allocation 

Auxiliary storage size and density defined by 
user; dynamically assigned storage. 

File Location 

Direct or indirect addressing; multi-indexes 
used. 

File Access Methods 

Sequential, indexed sequential, and random. 

Job Control Language 

Balanced orientation between verbs and para¬ 
meters. Sophisticated in its power, not overly 
complicated to use. Positional and keyword para¬ 
meters used; verbs (statements) positional in a 
given job stream. Reasonably self-documenting, 
although COMMENT card can be used if neces¬ 
sary. Interesting quirk is that all numerical 
values must be represented in octal. Control 
cards are grouped as follows: 

• Job identification (jobname). 

• File definition and identification (REQUEST, 
REWIND). 
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• Compilation and assembly (FTN, COBOL). 

• Loading and execution (LGO, LOAD, 
EXECUTE). 

• File and record manipulation (COPY, COM¬ 
PARE, SKIPF). 

Sorting and Merging 

Sort/Merge, a separate, independent program 
which operates under the control of Scope, exe¬ 
cutes in main core using the central processor. 

It utilizes hardware and software system capa¬ 
bilities and provides users with a variety of op¬ 
tional features. 

Sort/Merge resides in the system library and 
may be used independently as a main program 
with Scope control cards or incorporated into a 
larger system under program control by using 
macro calls. Methods used by the Sort/Merge 
program include the selection replacement tech¬ 
nique (a modification of the tournament sort) for 
internal sorting, and either the polyphase or 
balance technique for merging. The merge tech¬ 
nique is user selectable. 

The system may be used as a full sort and 
merge or a merge-only program. OWN CODE 
exit points exist where the user can enter auxil¬ 
iary routines for pre- and post-sort processing. 
Priority error processing and checkpoint restart 
options are available for system reliability. 

There are two variants of the Sort/Merge pro¬ 
gram: tape sort and disc sort. The minimum 
hardware configuration for the disc sort is the 
same as that required for Scope. But the tape 
version requires a minimum of four magnetic 
tape units. Disc overflow to tape is provided 
automatically. 

DESCRIPTION AND EVALUATION 

The characteristics of Scope place it in the 
category of a sophisticated operating system 
functionally, but it is simple and flexible from 
the user’s viewpoint. For example, users 
needn’t learn all the idiosyncrasies of the system 
to use it effectively and still maintain a fairly 
high level of efficiency. 

This report concentrates primarily on the 
functional aspects of Scope, with our evaluation 
comments included where germane. The follow¬ 
ing are a few of the more important features. 

Job Scheduling 

Like many operating systems, Scope schedules 
jobs principally by the numeric priority. It dif¬ 


fers however in that priority is not the only con¬ 
sideration: A job must also have available all the 
resources and core it requires to run to comple¬ 
tion before it begins execution. 

Overall we agree with the policy of requiring 
that sufficient resources be available to finish 
the job before starting it. It could be argued, 
however, that low-priority jobs would monopolize 
badly needed resources. This is indeed a good 
point; but neither the problem of having resources 
monopolized and thus denied to other jobs nor the 
problem of not having the resources available to 
finish the job will exist if users plan carefully be¬ 
fore assigning priorities, or jobs, to the job 
stream. 

The use of a numeric priority, as opposed to a 
combination numeric/job class priority scheme, 
is in our opinion a Scope weakness. With the job 
class numeric scheduling technique, a job can be 
assigned to a memory region or partition based 
on a weighting algorithm that considers both pri¬ 
orities. In addition, different time slice dura¬ 
tions can be assigned to these regions or parti¬ 
tions. OS/360 and 370 use this technique and so 
could Scope. Scope, as you will see later, uses 
seven peripheral processors, and seven control 
points (memory regions or partitions) to handle 
jobs, making it ideal for this sort of scheduling. 

Numeric priority is user assigned (or in de¬ 
fault, system assigned) and ranges from 1 (low¬ 
est) to 377 (highest). A job’s priority may be 
changed by the operator prior to selection of the 
job for processing. 

Jobs are assigned to control points in accor¬ 
dance with their priority. There are seven job- 
assignable control points.* A job’s position 
within its queue at the control point is determined 
on a FIFO basis; processing is performed round- 
robin intraqueue and linear priority interqueue. 

In selecting a job for processing, a higher- 
priority job always takes precedence over a 
lower-priority job, provided sufficient core stor¬ 
age and equipment required are available to ser¬ 
vice it. Once a job is selected for processing, it 
runs to completion unless interrupted by an event 
such as a forced interrupt or I/O request. The 
control information of an interrupted job is re¬ 
tained at its control point area, thus enabling the 
job to resume operation after the interrupt with¬ 
out losing its position in the job stack. 

Resource Allocation 

System resources, such as core storage, buff¬ 
ers, and I/O devices, are retained in a common 


* There are eight control points in all, but one 
is retained for use by the operating system. 
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pool and allocated and released automatically by 
the system on an as-needed basis. 

Jobs bound for the central processor are as¬ 
signed by the system to one of the seven avail¬ 
able control points. Control point zero is 
reserved for system functions, while the other 
seven are used to handle jobs. Thus up to seven 
user jobs can execute concurrently. Peripheral 
processors may also be assigned temporarily or 
permanently by the system to these control 
points. 

Central Memory . Central memory is com¬ 
posed of 32 logically independent banks of 4,096 
words. Each word is 60 bits. Scope assigns 
central memory from the common pool in a 
dynamic fashion to meet the needs of the request¬ 
ing program. The size of the program (its field 
length, to use CDC’s term) is indicated by the 
user on the job control card. This card also con¬ 
tains the job name, priority, equipment require¬ 
ments, operator instructions, and central pro¬ 
cessor time limit. The peripheral processor 
handling the job then requests the monitor to as¬ 
sign a block of contiguous core. If core is avail¬ 
able, the monitor assigns it a control point num¬ 
ber and sets a core reference address (similar 
to a base register) and a field length address 
(similar to a limit register). Storage is assigned 
to each program within the job as it is loaded. 

The core fragmentation (or checkerboarding) 
problem prevalent in OS/360 can occur in a minor 
form with SCOPE, even though it has a core com¬ 
paction capability. Like HoneywelPs OS/2000, 
Burroughs 1 MCP, and Univac T s Exec 8, Scope 
does not compact core after each job terminates; 
rather it determines if a queued job can fit into 
the vacated area even though it may not need all 
the available core. If one can, it enters even 
though the result might be checkerboarding. If 
none can, core compaction is done automatically. 

I/O Devices . I/O devices supported by Scope 
are magnetic tapes, discs, disc packs, drums, 
high-speed printers, card reader/punches, and 
keyboard/display consoles. Although codes do 
exist for allocating data cells, a paper tape 
reader/punch, and graphic data devices, no soft¬ 
ware support is provided. 

The designator and condition of each I/O de¬ 
vice assigned to the system is maintained in an 
equipment status table. Each table entry con¬ 
tains data showing: the device type, a flag field 
indicating device status (assigned or not), and 
such hardware information as channel and equip¬ 
ment number. All device assignments must be 
made through this table. 


A user can instruct the operator to assign a 
peripheral unit to a file and can declare the 
properties of that file and its assigned unit via a 
request card. With the request function, equip¬ 
ment can be assigned dynamically by a user pro¬ 
gram operating in the central processor. A 
request card or function must be given to assign 
a file directly to a private device. The device 
assigned to the requesting control point becomes 
the private source of destination of files for that 
job. As job control cards are processed in order, 
required private equipment assignments must 
precede any reference to the corresponding pri¬ 
vate file. 

If a file is not specifically assigned by a re¬ 
quest card or request function, then the system 
assigns that file to a disc storage. A job need not 
assign the card reader, printer, or punch for 
normal I/O for compilations, assemblies, and so 
forth, as this is done automatically by the system. 

If the assigned I/O device is not ready for some 
reason (cards not loaded in a card reader, for ex¬ 
ample), then a condition called peripheral pro¬ 
cessor recall results. Two forms of this recall 
are maintained by Scope: automatic and periodic. 
Both are invoked to keep as many peripheral 
processors as possible available to the system. 

Automatic recall uses a location in the control 
point area known as the peripheral processor re¬ 
call register. If a peripheral device is busy, a 
service routine writes the address of the assigned 
device in the recall register and requests the 
monitor to return the peripheral processor to the 
common pool. When the device is ready, the 
monitor assigns an available peripheral proces¬ 
sor to the waiting job, the device is attached, and 
processing continues. Periodic peripheral pro¬ 
cessor recall is basically the same but allows 
the user to specify the time period that will 
elapse before a pool peripheral processor is 
assigned. 

Disc packs, as previously pointed out, can be 
used with Scope. Like most disc packs, these 
require that all files be contained on a single 
disc; file overflow to a second pack isn’t possible. 

Scope maintains a channel status table indicat¬ 
ing the condition of each of the 12 hardware 
channels.* Any peripheral processor may con¬ 
nect to any channel. Before a peripheral pro¬ 
cessor can use a hardware channel, it must 
request it from the monitor. This is done to 
eliminate simultaneous requests for the same 
channel by different peripheral processors. 


*Scope also maintains seven pseudo channels, 
used exclusively for housekeeping functions. 


39 



CDC 6000 SERIES SCOPE OPERATING SYSTEM 


Program Loading 

Three program types are permitted: simple, 
planned overlay, and dynamic overlay. Segmented 
and overlayable programs permit programs that 
exceed storage to be organized so that portions 
or groups of programs may be called, executed, 
and delinked as needed. Segments and overlays 
cannot be intermixed, due to the loading pro¬ 
cedures involved. 

To facilitate loading and delinking, segments 
and overlays are identified by relative priority 
levels. A segment has only one level, while an 
overlay has two — a primary (or root) and a 
secondary. 

The loader links subprograms together and 
generates overlays as directed. A memory map 
is also created for all programs, except the 
main programs loaded from the system library. 
The loader operates in the central and peripheral 
processors. The central processor portion is 
loaded into the user’s job area. 

Programs are assembled or compiled inde¬ 
pendently, in absolute or relocatable binary. A 
number of programs may be grouped together as 
a segment to be loaded, linked, and, on request, 
later delinked and removed as a unit by the 
loader. The user defines the programs to be 
included in a segment either with control cards 
or with parameters included in the object pro¬ 
gram loader call. To facilitate reference to 
groups of programs, a segment definition may 
contain both program names and section names. 

A section is a convenience in the loader scheme 
to reduce the number of program names appear¬ 
ing in segment calls. 

Segments are loaded at levels ranging from 
0 to 77. Level zero is reserved for the initial, 
or main, segment. Segment zero must be the 
first segment defined; thereafter segments can 
be defined and loaded at any level. When a seg¬ 
ment is loaded, external references within the 
segment are linked to entry points in segments 
previously loaded at a lower level. Unsatisfied 
external references can be linked to entry points 
in segments loaded subsequently. 

Optionally, the user may specify that unsatis¬ 
fied external references be satisfied, if possible, 
from the system library, thereby nominally in¬ 
cluding certain library programs within a given 
segment. If the level requested for loading a 
segment is less than or equal to the level of the 
last loaded segment, the loader performs a de¬ 
linking operation. All segments previously 
loaded at a level equal to or greater than the 
presently requested level are removed, and all 


linking of external references to entry points 
within these segments is eliminated, causing the 
external references involved to become unsatis¬ 
fied again. Once delinking is complete, the seg¬ 
ment is loaded at the requested level. 

After an overlay deck has been entered, the 
loading procedure is terminated only when un¬ 
defined external references from the system 
library have been satisfied. The overlay and its 
identification are written as the next logical 
record in the file. Writing to the overlay file 
takes place when a directive is encountered which 
specifies an overlay level that would overlay a 
level currently residing in memory. Writing 
also takes place when the last overlay has been 
created. Each overlay has a unique entry that is 
the last transfer address encountered in the 
overlay programs during preparation. External 
references that cannot be satisfied, even by the 
system library, result in job termination after 
loading is completed; and maps are produced for 
all overlays. 

The 6000 Series implements its time sharing 
system by swapping programs between extended 
core storage and central memory. The roll-out, 
roll-in method is employed to provide the central 
processor with almost instantaneous access to 
any job and to minimize delay time when switch¬ 
ing between users. 

The loader includes the central program con¬ 
trol subroutine within the field length of each 
job. This subroutine provides the linkage be¬ 
tween user programs and Scope. All file action 
requests and system action requests are pro¬ 
cessed by the central program control library 
subroutine. The user’s programs communicate 
with the central program control through macro 
requests and the file environment table. 

It is interesting to note that errors encountered 
in assembly and compilation do not cause the 
system to terminate the job automatically. An 
error indicator is produced by the compiler or 
assembler and is written in the first record in 
the binary output file. The job terminates when 
the user attempts to load the program. 

Job Execution 

Once a job begins execution, it runs to com¬ 
pletion unless interrupted by an event such as an 
I/O or an aggressive interrupt such as operator- 
initiated rollout. Rollout is employed to appro¬ 
priate core and does not cause the interrupted 
job to lose its assigned devices or control point. 

Jobs awaiting execution after an interruption 
are stacked at their relevant control points. The 
top of the stack contains the job currently using 
the central processor. When interrupted, this 
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job is removed from the stack and its control 
information is stored in the control point area. The 
next job in the stack is then called (pops up) for 
execution. When the interrupted job is ready to 
resume processing, it reenters at the top of the 
stack and the job using the central processor is 
pushed down along with all jobs below it in 
the stack. 

During the course of processing, the monitor 
forces an interrupt every 64 milliseconds to ex¬ 
amine the condition of each checkpoint. Such 
checks are instituted principally to determine 
if (1) a previously interrupted job is awaiting re¬ 
entry and/or (2) a new job should be entered. 

Also, the monitor continually senses the status 
of each peripheral processor and the running 
program. When a service call arises, the mon¬ 
itor first determines if it can satisfy the request 
or whether it must pass it to a peripheral 
processor. 

The peripheral processors are used to per¬ 
form all I/O functions required by the system or 
processing program, as well as to handle certain 
functions associated with job sequence and con¬ 
trol. The actions performed by the peripheral 
processors are handled by relevant programs 
stored either in their memories, in main memory, 
or on the system disc. 

I/O Control 

The CDC 6400, 6500, and 6600 employ 12 bi¬ 
directional channels as the standard complement 
to service requests. Each system, however, can 
control as many additional operations as there are 
additional data channels. Channels are assigned 
by the monitor to peripheral processors on an as- 
available basis; the status of each channel is 
maintained in a channel status table. 

All calls for I/O are in the form of file action 
requests. Such requests cause control to pass 
from the executing program to a central program 
control subroutine, which initiates the I/O han¬ 
dling procedures. 

All I/O requests are queued according to their 
priorities. As devices become available, they 
can be assigned automatically by the system; 
or an I/O unit assignment can be defined by 
the operator. 

Remote Terminal Support 


Scope supports both interactive and remote 
batch processing through the Intercom 1 package. 
Teletype and display terminals can be used. Al¬ 
though neither type of terminal has off-line I/O 
equipment, cards can be punched or read and data 


printed on central-site peripheral equipment via 
commands issued from these terminals. 

Four types of files are supported by Intercom 
1: user private, common, system, and perma¬ 
nent. Private files are created by individual 
users and held on disc packs. At creation, they 
are designated to be processed only by the orig¬ 
inator, or they can be designated as public. 
System files are held in the Scope library and 
may be loaded but not modified or deleted by any 
user. Permanent files are simply mass storage 
files and are protected via safeguards specified 
by each file’s creator. 

Under time sharing, users may enter a pro¬ 
gram previously stored on disc, construct a 
file line for line at the terminal, compile a 
program, correct compilation errors via line 
editing, execute a compiled program, and save 
a program file for subsequent compilation or 
execution. Time sharing users also have the 
option of receiving or not receiving messages 
from other terminals; they can communicate with 
other terminals. 

In remote batch, files are submitted one at a 
time to the batch processing queue. The user 
first submits the name of the file, which the 
system in turn validates using the disc file 
directory. Then the user indicates the disposi¬ 
tion of the file, namely, place in input queue, re¬ 
name, make common or private, prepare for 
card punching. The system notes the disposition 
and places the file in the batch queue. 

Recovery Processing 


Scope provides a checkpoint/re start capability 
to recover from correctable hardware or soft¬ 
ware errors. This feature, however, cannot 
handle rolled-out jobs, random files, common 
files, multifile reels, and permanent files. A 
checkpoint dump can be requested by a check¬ 
point control card in the job stream, by an exe¬ 
cuting program (via a macro call), and by a con¬ 
sole request. 

When a checkpoint is invoked, the ’’total 
system environment” of the job is recorded on 
magnetic tape. Included in the checkpoint data 
are all local files associated with the control 
point; any permanent files attached to the con¬ 
trol point have their names recorded on the 
tape. If disc or drum files are being used, the 
total file contents and their relative positions 
within the file are captured. For magnetic tape, 
only the file’s relative position is recorded; the 
tape therefore must be repositioned during 
restart. 
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The restart feature is invoked via a control 
card and uses the checkpoint file as its data 
source. The checkpoint for restarting may be 
designated by name, number, or both. (Each 
checkpoint dump is automatically numbered in 
ascending order.) After locating the designated 
checkpoint dump, the restart program requests 
all files recorded and repositions them. The 
program also reestablishes all mass storage 
files from the copies appearing on the checkpoint 
tape, restores the central processor program, 
and restarts the job. 

Hardware Error Control 

The Scope capabilities for checking hardware 
errors are restricted mostly to a limited parity 
error checking capability. 

For example, parity error checking on data 
transferred within central memory is not done by 
Scope. There is also no provision that enables 
testing for I/O channel errors. 

Parity checks are performed on data trans¬ 
ferred to extended core storage. Any errors 
detected generate an error parity bit. 

A checkword is also generated after each sec¬ 
tor of disc storage is written. This word is 
tested against that sector’s checkword and, in 
the event of an error, sets a testable indicator. 
Data recording and recovery from disc packs are 
handled similarly on a record basis. Tele¬ 
communication transmission errors are detected 
in an analogous manner, using a checkword for 
each data block. Standard parity checks are rim 
on data recorded on magnetic tape. 

The single test routine provided as part of 
Scope is a memory diagnostic program. Called 
by the user, this program runs concurrently 
with problem programs to verify that the mem¬ 
ory modules are functioning properly. 

Testing and Debugging 

Three user-request able testing and debugging 
services are provided: program tracing, snap¬ 
shot dump, and label dump. The user requests 
these services via control cards submitted with 
his job deck. Trace and snapshot cards cause 
code that transfers control to the appropriate sys¬ 
tem routines to be placed in the user program. 

During tracing, instructions based on storage 
references, operand references, register usage, 
and branch instructions are analyzed. Trace 
output always includes a dump of the contents of 
all operand registers involved. An initial mes¬ 
sage indicates where tracing begins and the 


range involved. A terminal message is written 
when tracing stops. Tracing ranges can overlap, 
and multiple outputs can be triggered. 

The snapshot dump provides selective area 
printouts upon execution of specified instructions. 
Printing frequency is established by parameters 
on the snapshot control card. The dump can be 
provided in octal, octal with mnemonic op codes, 
integer, single- or double-precision floating 
point, or display code. 

Upon normal or abnormal job termination, 
three dump formats are available: octal (standard), 
labeled, and change. 

The format of a labeled dump is the same as 
for the octal dump, except as the origin of a com¬ 
mon block or subprogram is encountered, the 
associated name is printed. Also, a relative 
address counter indicates the position of the first 
word on the line relative to the last encountered 
subprogram or common block. 

The change option provides a list of core lo¬ 
cations that have changed from their initial 
values. When a job begins an execution phase, a 
core image of the entire field length is written on 
the debug file. The image is compared with the 
contents of memory at the time of termination, 
and the contents of changed locations are listed. 

A labeled dump always precedes a change dump. 

Utility Programs 

Scope performs integrated diagnostic routines 
to check the functioning of various system com¬ 
ponents (including central memory and the cen¬ 
tral processor’s functional units) during the pro¬ 
cessing of scheduled jobs. 

It also provides full accounting information 
for each job processed, at the conclusion of the 
job or upon operator request. Logged status 
data can be displayed on the system’s console 
device and/or line printer. Usage of the central 
processor, peripheral processors, and I/O de¬ 
vices is measured and displayed. 

A special accounting file, called the dayfile, 
contains all of the most significant information 
relating to the system run including control card 
data, equipment assignment, error diagnostics, 
central and peripheral processor time used, and 
I/O time. Besides the display monitoring, each 
dayfile is accounted with a job name; at job ter¬ 
mination, a printout occurs of all the job’s day- 
file messages. 

The operator can request a job status display 
that provides the status of all jobs being executed, 
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their control points, priority, and other informa¬ 
tion. A system file display shows the status of 
jobs to be executed. 

Support Utilities 

System support facilities, that is, routines 
enabling the system manager to obtain various 
statistics about operational use of the system, 
consist mainly of the dayfile. This file contains 
all significant information relating to the system 
run including control card data, equipment as¬ 
signments, error diagnostics, central and periph¬ 
eral processor time used, and I/O time. 

The dayfile is the data source for job account¬ 
ing routines which, unfortunately, are not part 


of Scope. It’s entirely up to the user to supply 
his own routines in this area. 

As an aid in determining if hardware compo¬ 
nents are going "soft," a separate error file is 
maintained to record such occurrences. This 
file indicates the component and its particular 
error and is used by maintenance personnel in 
determining which devices should be put off-line 
before catastrophic failure occurs. 

HEADQUARTERS 

Control Data Corporation 

P.O. Box 0 

Minneapolis, MN 55440 
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HIS 

Operating System/2000 (OS/2000) 


GENERAL 

OS/2000 is a fairly sophisticated operating 
system designed to provide the HIS 2000 Series 
computers with multiprogramming and telecom¬ 
munications capabilities. In the true sense, OS/ 
2000 is an evolutionary operating system, tracing 
its lineage to Honeywell’s OS/200. Functionally, 
both systems are quite similar; operationally, 
however, OS/2000 offers a number of significant 
enhancements, particularly in the areas of multi¬ 
programming support (15 processing core regions 
as opposed to 3), data base management, and 
communications management. 

The system is highly modular and can be gen¬ 
erated with widely varying configurations, de¬ 
pending on the needs of the installation. OS/2000, 
for example, can be SYSGENed to include up to 
15 separate, dynamically variable size memory 
regions. Of these, 10 are available for process¬ 
ing jobs (all batch, or all teleprocessing, or a 
combination of both*) and 5 are used for data 
transcription routines (i.e., spooling) buffers, 
schedulers, Mod 1 simulator, logical I/O rou¬ 
tines, data base management routines, call/can¬ 
cel routines and a MICH controller. 

The components comprising OS/2000 are di¬ 
vided into 2 main groups: supervisory and de¬ 
pendent. The supervisory components control all 
system activities and are concerned with job 
scheduling, program loading and starting, sched¬ 
uling processing time among the main core stor¬ 
age regions (Honeywell calls them partitions), 
and handling all data transfer operations. The 
resident monitor (nucleus programs) requires a 
minimum of between 12K to 28K characters (6 bits 
each), depending on the operating system version 
selected during system generation and on the num¬ 
ber of jobs to be controlled. 

The dependent components — so called because 
they operate under the influence of the supervi¬ 
sory components — are system programs dealing 
with disc data management, language translators, 
utility programs, sort programs, communica¬ 
tions programs, spooling, and report generation. 

Each processing memory partition must be 
requested in multiples of 4,096 (6-bit) charac¬ 
ters, and is hardware protected on this boundary. 
The minimum sjze is 8,192 characters and the 
maximum is 262,144 characters. Each partition 
contains its own program loader buffer, super¬ 
visor communication area, and control informa¬ 
tion; when active it is protected by the contents 

* Except when the Type 286 Multiline Communi¬ 
cations Controller is used, then teleprocessing 
can only be done in 1 foreground partition. 


of the base relocation register at the low end and 
the index barricade register at the high end. 

Programs operating under OS/2000 may be 
written as simple structure, planned overlay, or 
dynamic structure. 

MICH Support 

The MICR controller performs the physical 
I/O functions for the MICR device including start¬ 
ing and stopping, reading and pocket selection, 
detecting document/device errors, and storing 
MICR input data in a document queue after pocket 
selection has been performed. 

Communications Facilities 

OS/2000 supports either the Datanet 2000 or 
the Type 286 communications controller; how¬ 
ever, only one can exist in a single version of 
the system. 

Datanet 2000 processing incorporates a dual- 
processor capability: a communications proces¬ 
sor and an information processor. The informa¬ 
tion processor is the main Series 2000 or Series 
200 central processor; the communications pro¬ 
cessor is a Datanet 2000 communications proces¬ 
sor. The Datanet 2000 communications controller, 
a software element that resides entirely in the 
communications processor, handles communica¬ 
tions functions such as line handling, code 
translation, data queuing, and device handling. 

The Codasyl Cobol communications facility is 
supported. 

Memory overhead in the information proces¬ 
sor is minimized: a 4,096-character interface 
module resides in the lowest portion of a parti¬ 
tion — immediately above the resident monitor — 
and handles I/O functions between the communi¬ 
cations processor and information processor. 

The Type 286 communications controller 
handles code translation, message queuing, and 
device handling. Communications messages are 
routed to and from the central processor via a 
multiline communication controller (a multi¬ 
plexor). The communications controller accepts 
input messages from the multiplexor, queues 
them in memory or on disc, and transfers them 
upon request to the communications-processing 
program in memory (only 1 communications - 
processing program can be in memory at any 
given time). In a similar fashion, the communi¬ 
cations controller accepts output from the com¬ 
munications processing program, queues the out¬ 
put in memory or on disc, and sends it to re¬ 
questing remote stations via the multiplexor. 
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The communications processing program 
normally resides in a processing partition im¬ 
mediately above the communications controller. 
When communications processing is terminated, 
the space used by the communications controller 
and by the processing programs partition is re¬ 
turned to the common pool. 

LANGUAGE SUPPORT 

HIS provides three disc-oriented language 
translators to process source level programs 
written in Cobol, Fortran, and Easycoder (as¬ 
sembly language). In addition to normal func¬ 
tions, each translator also performs related ser¬ 
vices such as maintaining source language files. 

As an optional feature, each translator permits 
users to write program segments in different lan¬ 
guages which, in turn, are combined into a com¬ 
plete program at execution time. 

OPERATING ENVIRONMENT 

Minimum hardware requirements for OS/2000 
consist of 48K characters of main storage, one 
disc pack plus three magnetic tape units or three 
disc packs with no magnetic tape units, one line 
printer, one card reader, and one typewriter con¬ 
sole of Visual Information Control Console. All 
processors must be equipped with storage pro¬ 
tection and extended multiprogramming features. 

Despite its increased capabilities, OS/2000 is 
compatible with the OS/200 and Mod 1 operating 
systems and it functions with the following pro¬ 
cessors: Series 2000 Types 2032, 2032A, 2041, 
2041A, 2051A, 2051C, 2061, and 2071; and Se¬ 
ries 200 Types 1016C, 1201, 1251, 2016, 2201, 
3201, and 4201. 

FUNCTIONAL CHARACTERISTICS 

Job Types 

Batch, MICR, teleprocessing. 

Job Scheduling 

Job class-numeric combination; jobs serviced 
FIFO intraqueue and round-robin interqueue. 

Job linking by way of JCL permitted. 

/ 

Resource Allocation 

Main Storage: User specified, variable size 
regions. 

CPU Time: Fixed length 100 msec time slices. 


I/O Devices: Dynamically assigned and re¬ 
assigned; devices can be dedicated to a job or 
shared. 

Information Files: Dynamically assigned; 
read/write only access; nonreusable, serially 
reusable, and reentrant files permitted. 

Program Structure and Loading 

Simple, planned overlay and dynamic struc¬ 
tures; transient segment addresses computed at 
base zero. 

I/O Control 

Double buffering permitted; dynamically 
allocated. 

Remote Terminal 

Mixed line speeds; supports either the Datanet 
2000 or Type 286 communications controller, but 
only one can exist in a single version of the 
system. 

Recovery Processing 

Checkpoint/restart all jobs or a single parti¬ 
tion; user can restart from beginning of job or 
from job step, or a checkpoint within a job. 
Automatic restart (by way of JCL) is permissible. 
Tapes are repositional and discs are restored to 
position before checkpoint. 

Error Diagnostics 

Hardware and program errors recognized; 
error retried. 

Testing and Debugging 

No trace routines provided, but hooks are 
available for user routines; snapshot and post¬ 
mortem dumps permitted. 

File Management 

No system level catalog of files; no file back¬ 
up; user labels accepted. 

File Structure 

Sequential and indexed. 

File Storage Allocation 

Size and density defined by user; storage is 
dynamically allocated. 
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File Access Methods 

Sequential, indexed sequential, keyed, ran¬ 
dom, and telecommunications. 

Job Control Language 

Parameter oriented; consists of the following 
6 classes: 

• Job statement — marks the beginning of 
and identifies a job, including its expected 
use of system resources. 

• Resource Assignment (ASGN) — describes 
the data sets and device allocation requests 
of I/O resources. Also can specify limits 
of job use, e.g., DISM or RELSE can 
specify dismounting and system release 
respectively, of a specific resource. 

• Operator commands — PAUSE can allow 
an operator to reply to a system message. 

• EXEC statement — indicates the beginning 
of a job step and identifies the program to 
be used; PROC identifies a procedure to be 
used. 

• MODE defines an operating environment 
that stays in effect until EOJ or another 
MODE statement is encountered. 

• Delimiter statements — terminates various 
aspects of the input stream, including the 
input reader. 

Sorting and Merging 

OS/2000 provides 2 programs for sorting 
items in user-created data files; the sorting 
medium can be magnetic tape (tape sort) or disc 
(disc sort). 

The tape sort is composed of 4 processing 
modules (sorts F and V and collates F and V), 
which collectively offer extensive capabilities 
for rearranging data items on magnetic tape. 

Sort F uses a read-backward polyphase tech¬ 
nique to rearrange randomly distributed, fixed- 
length input items into ordered sequence; 1 for 
magnetic tape output. The sequence of sorted 
output items is based on a user-defined key field 
in each item. Input to the sort can be submitted 
from 1 or 2 magnetic tape units, the standard in¬ 
put unit, or own-coding. 

Sort V operates in a way similar to Sort F ex¬ 
cept that it processes variable-length items in 
variable-length records. 


Collate F combines 2 to 5 previously sorted 
tape files containing fixed-length items. A single 
sequential output tape file is produced. Collate V 
operates in a way similar to Collate F except that 
it processes variable-length items in variable- 
length records. 

A call cancel tape sort facility accepts data 
in fixed- and variable-length format from a call¬ 
ing program, arranges it in an ordered sequence, 
and transfers a single string of data back to the 
calling program. This sort is summoned into 
memory by the main program, performs the sort, 
and deletes itself upon completion. 

The disc sort can process all standard disc 
file organizations as well as magnetic tape files 
containing fixed-length items. Data can be sorted 
on a disc device in any of 3 ways: 

• A key sort, in which only keys and appended 
source-item addresses are sorted. 

• An extract sort, in which keys and selected 
data fields extracted from the source item 
are sorted. 

• An item sort, in which the entire source 
item is sorted. 

A replacement selection method is used for in¬ 
ternal sort operations; sort output can be pro¬ 
duced on a sequential output file (disc or magnetic 
tape) or provided to a user program. 

The sort provides item deletion and selection 
functions for a maximum of 20 fields each, and 
an item summarization function for a maximum 
of 21 fields. It also allows specification of up to 
20 key fields and 21 extract fields. Different col¬ 
lating sequences can be specified for each key 
field within a sort. The collating sequences may 
be binary, HIS commercial, IBM-compatible 
commercial, or zoned decimal. 

The sort uses an optimum merge order com¬ 
puted to minimize storage waste, seek time, 
latency, and data transfer time. A recovery op¬ 
tion is provided for work file processing. The 
sort consists of 5 phases (general assignment, 
presort, link, merge, and last pass). 


DESCRIPTION AND EVALUATION 

In overall simplicity of use, OS/2000 is in the 
same league as Burroughs medium systems MCP. 
Neither version, for example, requires the user 
to be totally familiar with all the idiosyncrasies 
of the operating system to use it effectively. The 
user, however, cannot be totally lax either. 
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The following paragraphs highlight the pre¬ 
dominant strengths and weaknesses of OS/2000. 

Job Scheduling 

OS/2000 employs a modified version of the job 
class-numeric technique to schedule jobs. There 
are 5 numeric priorities: number 1 (lowest) to 5 
(highest); and 4 processing priority schemes — 
urgent, high, medium, and low. Priorities are 
assigned by the user via JCL and can be modified 
by the operator through a console message. No 
job is scheduled unless sufficient resources are 
available to allow its running to completion. 

Within the numeric priority scheme, priorities 
1 through 3 are employed for normal processing. 
Priority 4 is for urgent jobs and has the capabil¬ 
ity of rolling out all other processing jobs in or¬ 
der to appropriate its resources (if needed). 
Priority 5 has the same privileges of priority 4, 
but is used for scheduling teleprocessing mode 
286 jobs. Up to 40 jobs in each priority class can 
be queued. 

The queuing technique employed by OS/2000 is 
fairly standard. Jobs with like numeric priorities 
are stacked in their respective queues and are 
serviced first-in, first-out as resources become 
available. Associated with each job, however, 
can be a "shadow priority" assigned by the user. 
The "shadow" is used when the programmer 
wishes to have one job linked to another and 
called when the owner job terminates. A call to 
dispatch the shadow job is done via JCL or by 
console command. 

Also associated with each job is a processing 
priority scheme which, for all intents and pur¬ 
poses, functions as a job class designator. By 
judiciously employing the scheme, a user can ef¬ 
fect a fairly good processing job mix. For ex¬ 
ample, a heavily compute bound job could be 
given a scheduling designator of 4 and a process¬ 
ing priority of low. This would guard against a 
high-priority compute bound job seizing control 
and holding it until interrupted. If a high sched¬ 
uling number and high processing priority were 
used, this could be disastrous if it weren T t for 
the fixed 100 msec time slice (or a forced inter¬ 
rupt) feature employed by OS/2000. Consequently, 
if someone doesn’t play it honest when scheduling 
jobs, he stands little chance of benefiting from it. 

A welcome addition to OS/2000, however, 
would be a start-time/deadline feature that would 
ensure low-priority jobs aren’t inadvertently 
buried in their job queues. In operation, the 
user-assigned start time would indicate when a 
job should be considered for execution; the dead¬ 


line specifies the elapsed time from submission 
until the job must be completed. Together they 
ensure that a low-priority job gets a shot at the 
CPU, and that a high-priority compute bound job 
doesn’t unreasonably delay lower-priority jobs 
from entering the system. HIS claims that the 
start-time/deadline feature will be included in 
the next OS/2000 release. 

Resource Allocation 

The system’s peripheral device configuration 
is described by the user during Supervisor gen¬ 
eration. Each time the system is initialized, the 
user can alter the equipment configuration. 

Initially all peripheral devices belong to a 
system device pool, and are dynamically assigned 
and released by the system in accordance with 
user-specified needs. Peripheral devices can be 
allocated for use in association with system and 
mnemonic files; for processing in a partition; or 
for use by the data transcription routines. If 10 
partitions are active concurrently, peripheral 
devices must be allocated to each partition for 
use by the jobs running in that partition. 

Device Assignment . Under OS/2000, all I/O 
requests are directed to mnemonic files rather 
than to specific peripheral devices. The assign¬ 
ment of peripherals to these mnemonic files is 
handled by the job scheduler in accordance with 
directions supplied by the JCL. Peripheral de¬ 
vices such as tapes, printers, readers, and 
punches may be allocated to a job for its exclu¬ 
sive use. 

Disc devices can be exempted from volume 
exclusivity through an optional volume sharing 
feature that lets 1 or more files be shared by 
concurrent jobs. Alternatively, 1 or more files 
can be reserved for the exclusive use of 1 job 
while remaining files remain available for com¬ 
mon use. 

Main Storage Allocation . Main storage is 
held in a common pool and assigned to programs 
as needed. The amount of storage allocated is 
determined by the size of the largest program or 
segment in the job; core can be released during 
job processing. 

Memory is always assigned to jobs in contig¬ 
uous blocks, the base-limit addresses of which 
are determined by the supervisor. Registers 
within the processor indicate the base of the ac¬ 
tive areas during program execution. 

OS/2000 accommodates programs organized 
into segments of varying sizes. A segment 
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dictionary indicates whether the segment is in 
memory or on disc and gives the corresponding 
main memory or disc address. Hence, no linking 
is required. 

To attain memory contiguity (that is, reduce if 
not totally eliminate memory checkerboarding) 
in any dynamic memory allocation environment, 
memory compaction is used. With compaction, 
the system scans memory to determine if non¬ 
contiguous areas have been vacated. If so, it re¬ 
organizes processing jobs to fill the vacant areas 
and resets the base limit registers. 

OS/2000 does not perform memory compaction 
after each job terminates. Rather, it scans the 
job queues and compacts only if the next sched¬ 
uled job requires compaction to acquire contig¬ 
uous core. However, the fact that the job fits 
does not necessarily mean it will fully utilize all 
memory in that area. Consequently, minor 
checkerboarding can occur under OS/2000. 

If the vacant contiguous memory area is too 
small to hold any waiting job, the system can fill 
it with utility routines or transitional supervisory 
components. 

System print and punch buffers are also held 
in a common pool and are automatically allocated. 
User programs do not have to request buffers to 
perform operations or replace them when the op¬ 
eration is finished. 

Job Initiation and Processing 

Although job scheduling is automatic under 
OS/2000, job initiation may or may not be — de¬ 
pending on the scheduling mode. Under one op¬ 
tion the system, via a console typeout, informs 
the operator of the name of the next job scheduled 
and, optionally, the magnetic tape file and disc 
volumes required. No job can begin until the op¬ 
erator directs it to do so. This arrangement will 
undoubtedly prove inconvenient to a number of 
users, particularly those running a large number 
of short turnaround jobs. For such circum¬ 
stances, the user can invoke automatic initiation 
through the job scheduler — a no-cost optional 
feature. 

Once a job begins processing, it runs to com¬ 
pletion unless an abnormal termination occurs 
or an aggressive interrupt is initiated. During 
processing the dispatcher gives an equal length 
time slice to individual jobs or to partitions run¬ 
ning a particular job class. Servicing of jobs or 
partitions can be carried out in a round-robin or 
linear manner, or a combination of both. 

Processing Support . In the event of an abnor¬ 
mal termination, the system displays the cause 


along with the contents of the registers involved. 
If the error is recoverable, an automatic restart 
is effected; if not, a memory dump is taken. 

Program restart can occur automatically (if 
so designated by JCL), or it can be user re¬ 
quested. A program can be restarted from its 
beginning or from its most recent user-taken 
checkpoint within the program. At program re¬ 
start, automatic recovery occurs for all mag¬ 
netic tape and disc files designated as recover¬ 
able. Recovery of a magnetic tape file consists 
of returning the tape reel to the position it oc¬ 
cupied at the restart point. Recovery of a disc 
file involves restoring the file’s contents as they 
existed at the restart point. To recover a disc 
file, the system uses the recovery information 
written on a recovery history file during 
processing. 

System Status . OS/2000 provides the capa¬ 
bility to display certain system status informa¬ 
tion upon request by the console operator. The 
Visual Information Control Console, or VICC 
(standard on the Type 2071 central processor, 
optional on other central processors), provides 
one display medium for this information, which 
includes the following elements: gross resource 
availability; processing priorities of active jobs; 
processing status of a specified partition; system 
processing status; contents of 1 or more job in¬ 
put queues; contents of print and/or punch output 
queues; abridged map of a specified disc volume; 
memory allocation map; device allocation map 
(peripheral devices in use); and file allocation 
map (disc files in use). All are available at the 
VICC display unit. 

If the equipment configuration does not include 
a VICC, the first 4 items mentioned are available 
at the console and the remainder can be listed on 
a line printer. Status information to be listed on 
a printer is stored in an intermediate disc file 
before transcription to the printer. 

File Management 

Before any volume can be assigned to an ap¬ 
plication, certain ’’housekeeping” functions — 
called volume preparation — must be performed. 

Volume preparation prepares a volume for use 
under the data management conventions of the 
system, creating a volume label, volume direc¬ 
tory, bootstrap routine, and (optionally) the sys¬ 
tem files used to provide the substitute track ca¬ 
pability. Volume preparation also performs 
certain track formatting (checking for bad surface 
areas), as requested by the user. 
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Alternatively, volume preparation can be run 
solely to change the bootstrap routine or the vol¬ 
ume serial number of a previously prepared 
volume. 

The volume label and volume directory provide 
information about a disc volume and all files 
stored on that volume, respectively. The volume 
directory consists of 3 sequential files that pro¬ 
vide information about all files stored wholly or 
in part on the volume. 

The bootstrap routine is a short loading pro¬ 
gram that permits a higher-level loader to be 
entered into memory. The bootstrap routine 
loads the OS/2000 supervisor into main memory 
as the first step in processing under OS/2000. 

The substitute track capability allows a good 
track to be substituted for each bad track. 

Volume Allocation . Volume allocation is 
handled by a routine that reserves space for disc 
files on 1 or more volumes, properly formatting 
the area(s) reserved for each file and appropri¬ 
ately updating the volume directory of each af¬ 
fected volume. A disc file must be allocated be¬ 
fore it can be loaded with data or used by another 
program. 

To expand a file, the allocator can be run re¬ 
peatedly, 1 unit of allocation at a time, up to a 
maximum limit of 6 units of allocation per vol¬ 
ume on 16 file volumes (a total of 96 units of 
allocation). 

Volume Deallocation . Volume deallocation 
deletes 1 or more disc files by removing all in¬ 
formation about each file from the volume direc¬ 
tory of every volume on which the file has been 
allocated. After a file has been deallocated, 
logical references to it are no longer possible. 
The space occupied by the file (including volume 
directory items related to the file) becomes 
available for other use. 

Data Management 

The data management facilities comprise 
physical and logical I/O handling routines, plus a 
data base file management module. Physical I/O 
routines are fairly standard in that they locate 
files or volumes, read user and system standard 
labels, and schedule channels to transfer data. 

Logical I/O Facilities. Logical I/O supports 
sequential, partitioned sequential, indexed se¬ 
quential, and direct access disc file organizations, 
as well as sequential files on magnetic tape. It 
also allows users to assign a sequential file to 


disc or magnetic tape at program execution time 
without the necessity of re specializing program 
code for a specific device type. 

Logical I/O consists of macro routines and 
preassembled processing routines that open and 
close a file; read an item from a file and write 
an item to a file; insert, delete, or replace 
items in a file; process the member index of a 
partitioned sequential file; position a file to a 
specified item or label; force an end-of-volume 
condition in a file; and release a file from 
processing. 

Logical I/O processing routines are divided 
into 2 categories: overlay and resident. Over¬ 
lay routines (commonly used routines that are 
largely independent of file type) are executed in 
one of the overlay areas within the resident moni¬ 
tor. Resident routines (routines specific to a 
particular file type) are executed within the pro¬ 
gram partition. This arrangement minimizes the 
amount of memory required to supply logical I/O 
in a program partition, for the partition need 
contain only those logical I/O resident routines 
required by the program being run. 

Each logical I/O macro call coded into a user 
program performs one of the following functions: 
describes a file to be processed; specifies which 
preassembled processing routines are to be resi¬ 
dent in the program partition; and calls for ex¬ 
ecution of a processing routine. 

Exits are provided so that user-written rou¬ 
tines can process error conditions or special 
data conditions. In addition, logical I/O provides 
a full set of error diagnostics and warning mes¬ 
sages to complement system-provided control 
functions for logical I/O processing. 

Data Base File Management . HIS employs 
Cincom T s Total data base management system. 
Total is intended for 65K-byte systems and above 
and requires a separate memory partition. 

A rather unique system, it employs the net¬ 
work structure of data organization (that is, for¬ 
ward and backward pointers to show data re¬ 
lationships) and is independent of host languages 
and secondary storage devices. Total functions 
strictly as a subroutine and is incorporated into 
the application program on a call or macro level. 

Information Storage and Retrieval 

OS/2000 also offers the Easywriter subsys¬ 
tem. Easywriter is a combination data manage¬ 
ment language and information storage and re¬ 
trieval (IS&R) system that allows users to extract 
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data from standard OS/2000 files, manipulate the 
data, and produce up to 63 different reports with 
1 interrogation. 

Conceptually, Easywriter is typical of the 
newer IS&R systems in that it permits nonpro¬ 
grammers to query the data base via a simple 
English-like syntax. It differs in that the queries 
may be either written on preprinted forms and 
converted to cards for system entry, or they 
may be formed at a local or remote terminal. 
(Most IS&R systems do not offer both techniques.) 
The latter method employs a free-form syntax, 
which contains all the expressions of the elemen¬ 
tary query language used with the forms plus ad¬ 
ditional expressions to meet special data selec¬ 
tion, manipulation and formatting requirements. 

SUPPORT UTILITIES 

Job Accounting 

OS/2000 provides facilities to account for sys¬ 
tem resources used by each program within a 
log file editing program. This program can edit 
the file to printer in 1 of 2 formats. It can build 
a vault copy (optional feature) of the log informa¬ 
tion. It is written in Cobol and is visible to the 
user so he can structure his own program to 
manipulate the accounting data to suit his own 
requirements. 

Detailed accounting information can be written 
on a disc log file and/or brief accounting infor¬ 
mation can be displayed on the console. Such ac¬ 
counting information consists of date; account 
identification; job name and program name; job 
priority; program start time, stop time, and 
elapsed time. In addition, the system records 


CPU time used (only for central processors 
equipped with a high-resolution clock); main 
memory used; peripheral devices used (by de¬ 
vice type); number of print images; number of 
card images punched; number of card images 
read; and program termination status (normal 
or unusual). 

Testing and Debugging 

A number of software testing and debugging 
facilities are offered as standard system and 
component features. Among these are included 
memory, tape and disc dump routines at unusual 
end-of-program time, and file editing programs. 

A Cobol debugging facility gives the program¬ 
mer a powerful object-time debugging tool. It 
enables him to trace the execution path of his 
program and to validate the contents of selected 
data items at specified points during processing. 
The compiler is made to respond to external 
direction indicating whether to ignore or process 
the debugging procedures. Information to be 
monitored and/or displayed is determined en¬ 
tirely by the programmer; the debugging facility 
provides convenient access to that information. 

OS/2000 Fortran provides 2 types of debugging 
techniques: a data trace and a flow trace. The 
data trace statements control the tracing of a 
Fortran program’s visible data, beginning or 
ending at any point, including array elements. 

The flow trace statements will cause a listing of 
statement labels in the order of their execution. 

HEADQUARTERS 

Honeywell Information Systems 

60 Walnut Street 

Wellesley Hills, MA 02181 
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HONEYWELL INFORMATION SYSTEMS 

6000 Series GECOS III 


GENERAL 

The General Comprehensive Operating System 
(GECOS), designed for the HIS 6000 Series, em¬ 
ploys multiprogramming and multiprocessing 
techniques which permit the concurrent execu¬ 
tion of up to 63 jobs. GECOS incorporates what 
the vendor calls a "three dimensional design," 
which means it provides time sharing facilities 
in conjunction with local and remote batch. Local 
and remote batch jobs are processed in the same 
manner, the only difference being in the input 
and output routines that interface with the com¬ 
munications processor. 

Initial job selection is based on priority and 
the availability of peripheral devices. A high- 
priority program can force one or more of the 
programs being executed to be "swapped out" of 
memory temporarily. GECOS allocates to the 
job the available system resources (processors, 
memory, and peripherals). All physical input/ 
output considerations are handled by GECOS, 
with input/output supervision on an interrupt- 
oriented basis. Programming is file oriented 
on a logical level rather than device oriented. 

Permanent on-line files are provided that can 
be read by multiple programs in a multipro¬ 
gramming context. However, any file can be up¬ 
dated at any given time by only one program. 
Memory protect capability is provided. Un¬ 
authorized access to confidential data files is 
prevented by personal password protection, and 
all remote users must be validated before ac¬ 
cessing the system. 

GECOS is structured to complete five specific 
phases in the course of processing a job flow. 
These phases include job input, activity alloca¬ 
tion, activity execution, activity/job termina¬ 
tion, and job output. The term "activity" refers 
to any single program (such as a Cobol compila¬ 
tion or any object program load or execution), 
while the term "job" refers to a set of sequen¬ 
tially executed, related activities, which together 
constitute an application. 

A multiprocessing environment operates to 
handle a large number of activities that are ready 
for processing. GECOS distributes activities, 
tables, buffers, service routines, and so on, 
with a minimum of "gating" and minimizes multi¬ 
processor interference for memory access. 

Major program service functions that might 
cause interference are performed in parallel by 
providing each program with an individual copy 
of the service function. 

GECOS offers high level language support in 
the form of ANSI Cobol, Fortran IV, Jovial, and 
GMAP (assembly language). 


Remote Access 

Remote processing is realized through the 
Datanet communications processors. Up to three 
Datanet 30 T s or Datanet 355 are permissible. 

Any job that can be entered at the central system 
site can be entered remotely, since a remote 
batch job differs from a local job only in GECOS 
I/O routines used. 

Remote access also includes a reactive termi¬ 
nal interface which provides direct terminal ac¬ 
cess to remote batch jobs in execution. In effect, 
the terminal is an on-line peripheral unit that can 
receive requests for input from the activities at 
the main system site. Remote batch job output 
files can be returned to the sending terminal, 
entered into the GECOS file system, output at a 
central site, held until the terminal calls back, 
or sent to another terminal. 

Remote terminals can communicate in direct 
access mode with a processing program. In this 
mode the terminal processing routines are by¬ 
passed, and data is transmitted directly to and 
from the terminal by a user program. Thus in¬ 
quiry type teleprocessing applications are 
possible. 

Time Sharing 

The core-resident Time Sharing Executive is 
structured as a slave program to GECOS. It 
performs the functions of selecting, allocating, 
dispatching, and swapping time sharing user 
programs. In addition, it suballocates memory 
and subdispatches the processor to the individual 
time sharing programs. The executive resets 
the base register to protect the other programs 
in memory. 

All terminal input/output security arrange¬ 
ments are controlled by the executive. It also 
accounts for the resources used by the individual 
time sharing users. The same priority scheme 
for memory swapout applies. GECOS time shar¬ 
ing makes use of the remote terminal service 
executive, which permits a combination of re¬ 
mote batch processing and time sharing to be 
performed with a single communications 
processor. 

Sorting and Merging 

The Sort/Merge program, which actually is 
the old GE 625/635 utility, is a generalized sys¬ 
tem providing sort and merge capabilities tailor¬ 
ed to specific applications. The system is gen¬ 
eralized in the sense that it reads parametric 
task descriptions, adjusts itself to the task in a 
negligible amount of time, and performs it. 
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This program is accessed through the Macro 
Assembler (GMAP). A normal, straightforward 
request for a sort or merge function, or the dual 
function of a sort followed by a merge, is accom¬ 
modated by a series of three macro calls that 
describe the essential parameter and establish a 
calling sequence to the System Software Library 
File. The result of the assembly is loaded, and 
the calling sequence is executed to bring the sort 
or merge system into memory from the system 
file. It then adapts itself to provide a program 
for sorting or merging according to the descrip¬ 
tive parameters specified. 

Standard functions of the Sort/Merge program 
are preset for generalized sorting and merging 
applications. Thus, the number of parameters 
required with the macro calls are relatively few 
for the average sorting or merging problem. 
However, the program can be adjusted to handle 
a wide range of sorting and merging problems. 
This feature is available through the use of op¬ 
tional parameters in the required macro calls 
and through other optional supplemental macro 
calls. Further flexibility in handling unusual 
sorting and merging problems can be attained by 
the user’s own coding, which can be called 
through the use of a supplemental macro call. 

The program will accept GMAP symbolic coding 
prepared by the user. These User Coding Ele¬ 
ments can be added to the programs to prepro¬ 
cess input files, to accomplish unusual record 
key comparisons, to combine or eliminate data 
records with duplicate keys, and to process out¬ 
put data as its final position in the file is 
established. 

Sort programs arrange the records of a data 
file in sequential order with respect to their se¬ 
quence key values. Among the many uses for a 
sort program are: 

• Establishing the initial order of a newly 
created master file. 

• Arranging a transaction file into the master 
file order for convenient updating. 

• Arranging records into a special order for 
reporting. 

• Correcting minor sequence deviations in a 
nearly well ordered file. 

• Arranging data according to the magnitude 
of selected parameters. 

The input file is normally assumed to be arbi¬ 
trarily disordered. In a series of magnetic tape 
manipulations, the records are redistributed and 
gathered together until they are finally delivered 


to the output file in the desired order. If the in¬ 
put could all be held in the computer memory at 
one time, no recourse to magnetic tape would be 
required, and sorting could be done entirely by 
internal key comparisons. This is sometimes 
possible for small amounts of data. For such 
applications the use of an internal memory sort 
is recommended. Although such a small amount 
of data is quite acceptable, the Sort/Merge pro¬ 
gram is designed to handle very large amounts 
of data. 

Merge programs combine several sequential 
input files into a single sequential output file. 
Among the many merge program uses are: 

• Reducing several newly sorted files to a 
single file. 

• Periodically incorporating new records into 
a cumulative file. 

• Matching transaction records from several 
files against a master file. 

The purpose of this Sort/Merge program is to 
accomplish both the sort and the merge functions 
efficiently for all data files. 

Considerable flexibility is required for such a 
program to serve effectively in a broad range of 
applications. The recognition of this need is 
fundamental to the program’s design, as the fol¬ 
lowing properties illustrate: 

• The task requested can be a sort, merge, 
or dual function. (The dual function is a 
sort that includes a merge of a well ordered 
file.) 

• The task is described on macro call cards, 
whose parameters and options permit the 
description to be either quite simple or 
highly complex. 

• Internally, the program is built to respond 
optimally to each possible combination of 
input parameters. 

• The program is organized into several sub¬ 
programs, which successively overlay each 
other in memory. 

• Each subprogram is further subdivided into 
many small modules, and only the modules 
required for the task described occupy 
memory while the task is performed. 

• Highly variable procedures, such as key 
comparison and record selection routines, 
are generated at execution time so that they 
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can be completely tailored to the task at 
hand. 

• The program automatically optimizes its 
use of core storage and magnetic tapes. 

This Sort/Merge program defined by normal 
options will process magnetic tape data files with 
the following characteristics: 

• Individual logical record sizes ranging from 
one to 4192 words (36 bits each). 

• Magnetic tape physical record blocks rang¬ 
ing from one to 4192 words. 

• Any number of reels of magnetic tape. 

• Conventional GE magnetic tape file stan¬ 
dards. 

• One to 99 scattered sequence subkeys 
occupying from one to 99 consecutive bits 
or characters. 

Operating Environment 

A minimum hardware configuration for running 
GECOS is a 6000 Series processor with 64K words 
of core storage, an input/output controller, a 
console typewriter, six magnetic tape units, one 
card reader, one printer, and one disc with 30 
million characters. 

FUNCTIONAL CHARACTERISTICS 

Job Types 

Local and remote batch; time-sharing inCobol, 
Fortran, and Jovial permitted but no line-by- 
line entry. 

Job Scheduling 

Numeric priority only; jobs scheduled FIFO 
provided sufficient resources are available. Up 
to 63 jobs can run concurrently. 

Resource Allocation 

Main Storage: dynamically assigned fixed size 
regions; core compaction performed as needed. 
CPU Time: indefinite time slice. I/O Devices: 
dynamically assigned from common pool. In¬ 
formation Files: shareable and nonshareable 
programs and subroutines permitted on a read 
only basis. 

Program Structure and Loading 

Simple or user specified variable size 
overlays. 


I/O Control 

Device Types: disc, magnetic tape, type¬ 
writer, unit record devices, and video display. 
Scheduling Performed: physical device only. 
Buffer Allocation: single or double buffering; 
simple allocation only (no dynamic buffering). 
Remote Terminal Support: standard terminal 
speed and format. 

Recovery Processing 

Checkpoint or restart all jobs; roll-in or roll¬ 
out all jobs; I/O devices not repositioned when 
job is interrupted by higher priority job. 

Diagnostic Error Processing 

Hardware and program errors recognized and 
serviced; minor errors retried before termina¬ 
tion. Error statistics kept. On-line diagnostics 
ensure hardware integrity. 

Processing Support 

Timing Services: interval and real-time. 
Testing and Debugging: postmortem and snap¬ 
shot dumps. 

Logging and Accounting 

Standard accounting data for local and remote 
batch jobs. No billing programs provided. 

File Management 

Libraries of source code and executable code. 
File Structure 

Sequential, random, and indexed random. 

File Storage Allocation 

Auxiliary storage defined by user; storage 
assigned dynamically. 

File Location 

File name only using master catalog. 

File Access Methods 

Serial, random, and indexed random. 

Job Control Language 

Fixed format using both positional and key¬ 
word parameters. Default options are assumed 
for many of the parameters. Message formats 
for problem program are not standardized. A 
special macro is used to inform the operator 
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that a message requires a response. If no re¬ 
sponse is received after a 30 second interval, 
the console terminates the read command with a 
status indication to the requesting program. 

DESCRIPTION AND EVALUATION 

GECOS is another one of those operating sys¬ 
tems that will do a fairly good job provided you 
take care in scheduling work. Resource con¬ 
flicts must be guarded against in particular. 

The following paragraphs highlight some of 
the more important aspects of GECOS and pre¬ 
sent commentary on their strengths and 
weaknesses. 

Job Scheduling 

GECOS employs a straight numeric priority 
scheme to schedule jobs. Up to 63 user assigned 
numeric designators, which range from one 
(highest) to 63 (lowest), are permitted. All time 
sharing jobs are treated as one entry. All high 
priority jobs are serviced before lower priority 
members. Jobs are serviced FIFO interqueue 
and round-robin intraqueue. No job is scheduled 
for processing unless it has sufficient resources 
to allow it to run to completion. If a job fails to 
gain resources after a certain number of at - 
tempts, the operator is notified so that he may 
increase the priority. If the job fails to get 
memory after a certain number of tries, its 
priority is automatically increased. Both fea¬ 
tures constitute a quasi-passover limit schedul¬ 
ing technique, which on the whole is excellent. 

Programs are entered into an input queue 
from the local job stream or from a remote ter¬ 
minal. Each job is examined for resource re¬ 
quirements; if sufficient peripherals and main 
core are available, the job is moved to the dis¬ 
patching queue. If resources are lacking the job 
remains in its input queue, and the next job in 
that queue is given a shot at being scheduled. 

When a high priority job is entered for which 
sufficient resources are unavailable, the operator 
is informed. He can then raise the priority to a 
level where peripheral allocation for other activ¬ 
ities are suspended until this job’s requirements 
are met. For very high priority jobs, executing 
tasks are suspended and rolled out to make room 
in memory. 

The numeric priority scheme, even with the 
quasi-passover scheme, has two outstanding 
weaknesses: It services higher priority jobs to 
the total exclusion of their lower priority broth¬ 
ers; and it can waste system resources. With 


straight numeric, no thought is given to estab¬ 
lishing and maintaining a balanced priority job 
mix, and the effective utilization of resources 
becomes a secondary consideration. Everything 
is sacrificed to service the high priority job. 

Some systems employing the straight numeric 
technique do not permit even the highest priority 
job to ’’crash out” or indiscriminately roll-out one 
or more lower priority jobs just to get their re¬ 
sources. They require the operator to make the 
decision. Operator approval is required for 
certain classes of jobs under GECOS but not all. 
And that’s the rub; we feel the danger of reduc¬ 
ing throughput and the possibility of wasting re¬ 
sources by rolling out two or more jobs that are 
processing effectively could be greatly reduced 
by having the operator make the interrupt 
decision. 

Resource Allocation 

System resources, with the exception of I/O 
buffers, are assigned dynamically in accordance 
with the priority of the job and its needs. 

Main Memory . The maximum amount of in¬ 
ternal storage required by the job is contained 
in a parameter on the job control card. There 
are three levels of memory allocation. Jobs of 
normal priority are allocated memory only if a 
contiguous area large enough for the job is avail¬ 
able. Memory is allocated in multiples of 1024- 
word blocks. A word is 36 bits long. A higher 
level of priority will cause memory compaction 
to occur making noncontiguous areas of unused 
core contiguous. The highest level of priority 
will cause other jobs in execution to be removed 
from memory (rolled-out) to provide sufficient 
storage. Each time a job fails to obtain suffi¬ 
cient memory for execution, its priority level 
is increased. During program execution, 
internal storage may be dynamically allocated 
through requests for additional storage. The sys¬ 
tem also allows a common communications area 
for tasks within a job. 

Peripherals. I/O devices are normally allo¬ 
cated by device type (for example, tape or disc); 
however, under certain circumstances, alloca¬ 
tion may be by physical device identification. File 
sharing (on a read only basis) is permitted among 
any number of separate programs. However, only 
one program at a time is permitted write access 
to the file. 

Supervisor facilities exist that permit the 
problem program to dynamically request addi¬ 
tional peripherals. Dynamic peripheral requests 
are limited to tape handlers and to existing files 
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allocated on mass storage (disc and drum) de¬ 
vices. The implicit files used by the compilers 
and system routines (such as the files used to 
hold user jobs or those used as intermediate files 
during compilation) can also be allocated 
dynamically. 

Resident system subroutines can be either re¬ 
entrant or serially reusable. Though lockout fa¬ 
cilities are provided for the serially reusable 
routines, the system prefers to provide multiple 
copies when feasible to avoid the problem of task 
suspension due to a lockout. For example, the 
subset of file control routines required for pro¬ 
gram execution is appended to the problem pro¬ 
gram at program load time and maintained as a 
part of the user program. 

Input/Output Control 

During execution GECOS initiates all input/ 
output operations in the master mode. The input/ 
output controller (IOC) modules then proceed with 
the input/output execution, using data prepared 
by GECOS and stored in the IOC mailbox area. 

GECOS provides the logical interface for the 
file processing offered by the General File/ 
Record Control routines. The status of devices, 
files, and memory areas is checked for avail¬ 
ability. All of the input/output requests are 
queued by peripheral channel. To reduce disc 
and drum rotational delays, the system scans the 
channel queue to determine which input/output 
operation can be most efficiently executed with 
regard to device position. Devices can be inter¬ 
changed during execution through operator notifi¬ 
cation in the case of device failure; the system 
keeps track of the number of files involved and 
number of records within each file, so reposition¬ 
ing can be accomplished. GECOS also provides 
device independence by simulating (when re¬ 
quested) the serial processing of magnetic tapes 
on either drum or disc. 

Various input/output functions are performed 
by associated library programs consisting of 
GEFRC, GELOAD, GERTS, and BMC. 

GEFRC, the General File/Record Control 
routine, is the normal means for controlling 
input/output operations. All compilers and job 
programs generated by compilers access the in¬ 
put/output control routines of GECOS through 
GEFRC. Programmers using symbolic language 
can also use GEFRC. A n File Control Block” 
must be constructed for each file to be used. 


This is produced automatically by the compilers 
but must be written by the programmer for sym¬ 
bolic-language programs. Every File Control 
Block contains such information as record length, 
block length, file name, and file code. At load 
time control cards, which reference the file by 
its file code, specify the type of device to which 
the file is to be assigned. GEFRC will automati¬ 
cally handle blocking or deblocking of records, 
buffer alternation, label processing, unit swap¬ 
ping, and movement of records between buffers 
and working areas. 

GELOAD, the General Loader, is used to 
transfer programs from temporary mass storage 
to core storage when they have been scheduled 
for execution. It will also: relocate subprograms 
into one contiguous program and establish the re¬ 
quired linkages; store and establish the required 
linkages for overlay segments; provide debug fa¬ 
cilities (debug statement cards are read at load 
time, and snapshot printouts of specific locations 
within a program are made at execution time); 
call in other programs; create a file control block 
for I/O; provide options for selected printout dur¬ 
ing execution; and provide a load map. 

GERTS, the GE Remote Terminal Supervisor, 
supervises ail remote terminal input and output. 
For remote access batch jobs, input is sent to 
the system input queue, and output is received 
from the system output module. 

Time Sharing 

Those using GECOS in a time sharing mode 
can avail themselves of an excellent text editor 
facility. The text editor subsystem allows a 
user to enter text, edit it, and retrieve it. The 
text can be of any kind: letters, lists, manuals, 
business records, or programs for other 
subsystems. 

The text editor appears to be especially well 
suited for form letters, mailing lists, invento¬ 
ries — all of which often need individual items 
changed. Portions of the text can be added, de¬ 
leted, or modified with changing the surrounding 
text. 


HEADQUARTERS 

Honeywell Information Systems 
13430 N. Black Canyon Highway 
Phoenix AZ 85005 
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IBM CORPORATION 

Operating System/360 and 370 


GENERAL 

OS/360 is a comprehensive set of control and 
processing programs integrated within a super¬ 
visor network to provide coordinated and contin¬ 
uous operation of medium- to large-scale Sys¬ 
tem/360 and nonvirtual 370 computer systems. 

The heart of OS/360 is the supervisor (execu¬ 
tive) routines. These routines allocate main 
storage to jobs and control the sharing of com¬ 
mon areas of main storage; load object programs; 
control the concurrent execution of programs and 
routines; provide timing services and job ac¬ 
counting information; support remote job entry; 
and perform such program modification as up¬ 
dating and replacement, insertion, deletion, edit¬ 
ing, renumbering, copy, combining, and syntax 
checking. OS/360 is modular, so additional con¬ 
trol facilities can be assembled into the system 
as desired, provided enough core and auxiliary 
storage is available. 

The processing programs provided and con¬ 
trolled by the OS/360 include language transla¬ 
tors, service programs, and the user’s own 
problem programs. Language translators are 
designed at 4 basic levels: E, F, G, and H. 

These letters generally correspond to the desig¬ 
nations of the core storage units that accommo¬ 
date the programs. For example, an E-level 
program fits into a System/360 Model 40E pro¬ 
cessor (32K bytes of core storage); an F-level 
program into a System/360 Model F processor 
(65K bytes of core storage); an H-level program 
fits into a System/360 Model H processor (262K 
bytes of core storage). The smaller versions 
are, in all cases, proper language subsets of the 
larger, complete language versions. 

Like all programs controlled by OS/360, the 
language translators can make use of any avail¬ 
able control services of the operating system. 

The currently announced language translators 
available with OS/360 include E- and F-level as¬ 
semblers; G- and H-level Fortran IV; E-level 
RPG; and F-level versions of Cobol, PL/l, and 
Algol. 

Operating Environment 

Minimum system facilities needed to support 
the system vary with the version chosen. Disc 
files and/or magnetic drum storage devices and 
a theoretical minimum of 32K bytes of core stor¬ 
age are prerequisites for use of OS/360. How¬ 
ever, even its most basic versions require at 
least 65K bytes of core storage, with only small 
satellite systems using 32K-byte software. 


Large multiprogramming versions of OS/360 
can require up to 200K bytes of storage for resi¬ 
dent control programs, resulting in operating 
environments of 524K bytes of core storage. 
Typical hardware configurations for implement¬ 
ing OS/360 require at least 1 multiplexor chan¬ 
nel as well as 1 selector channel for PCP and at 
least 2 selector channels for MFT and MVT. 

SYSTEM VERSIONS OF OS/360 

OS exists in 3 versions: The Primary Control 
Program (PCP) with a sequential scheduler; 
Multiprogramming with a Fixed Number of Tasks 
(MFT), Version II and Multiprogramming with a 
Variable Number of Tasks (MVT). Each offers 
the facilities for primary data management; and 
each contains a supervisor that provides for 
overlapping processor operations with I/O activ¬ 
ity, supervises the processing of interrupts, and 
handles error checking and I/O error recovery 
procedures. 

PCP is the basic version and requires the 
least storage; MFT is next in complexity and 
needs additional storage; MVT is the most com¬ 
plex and requires still more storage. The ac¬ 
tual amount of storage necessary is a function of 
the operating system, configuration, and features 
chosen and varies with installations. 

PCP 

Although in maintenance since 1970 and un¬ 
available on System/370, the features of PCP 
form the core of OS/MFT and MVT and therefore 
are worth reviewing. 

Major components of the PCP control system 
are a resident supervisor and a transient sched¬ 
uler program. The PCP supervisor controls the 
sequential execution of programs and provides 
the routines required to handle exception condi¬ 
tions that arise during processing and control 
I/O routines. Many of the supervisor routines 
can be called by macroinstructions within user 
programs. PCP supervisor resides permanently 
in core storage, and in its most basic form re¬ 
quires at least 12K bytes. An additional allotment 
of core storage, typically between IK and 2K 
bytes, is required for residence of the super¬ 
visor’s I/O routines and control tables. 

Principal specific functions provided by the 
PCP supervisor are: control of execution of a 
single program; overlap of I/O operations with 
computing; storage of I/O requests in queues; 
supervision of interrupt handling; allocation of 
main storage at load time and storage protection; 
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control of program overlay handling; and loading 
of relocatable object programs by dynamic over¬ 
lay macros. 

Other functions are system error checking, 
including I/O error recovery procedures; logging 
of machine malfunctions; locating, loading, and 
execution of named programs; specifying of user 
control for some program interrupts; waiting for 
and posting of notices for completion of events; 
operator communications; and setting, testing, 
and resetting of timers. 

PCP sequential scheduler is brought into core 
storage between job steps and generally requires 
about 18K bytes of memory. Two other sequen¬ 
tial schedulers (44K- and lOOK-byte sizes) im¬ 
prove performance in the job scheduling opera¬ 
tions by reducing the number of scheduler load 
modules that must be brought into core storage 
to complete the scheduling operations. 

The sequential scheduler regulates the auto¬ 
matic flow of jobs through the computer system, 
handles I/O device allocation, and serves as the 
interface between user and system through use of 
the standard System/360 job control language, 
operator commands, and console messages. 
Further, the sequential scheduler supports: 

• Reading and interpreting of control state¬ 
ments using all features of the job control 
language except those that pertain to prior¬ 
ity, system log, message class, job step 
timing, or report writers. 

• Alternate console or composite console 
options. 

• Storage of frequently used sets of job con¬ 
trol statements in a procedure library, and 
to summon these procedures into core stor¬ 
age for execution by specifying only the 
procedure name. 

Multiprogramming with a Fixed Number of Tasks 

MFT is the second level of OS/360. It per¬ 
forms all of the functions of PCP and includes 
several improvements and additional capabilities. 

The major extension of MFT over PCP is 
MFT's partitioned core storage environment. 

With this extension, a priority can be assigned 
to each partition in order to assure time-sensi¬ 
tive jobs (such as data communications and 
graphic displays) appropriate access to system 
resources. The maximum number of partitions 
and the size of each are defined by the user at 
system generation time. Reductions of the num¬ 


ber of partitions and their sizes can be per¬ 
formed by the operator at initial program load 
time or dynamically during execution. Minimum 
allowable partition size is 8K bytes, but one sys¬ 
tem reader must be the size of the scheduler (or 
larger), i.e., 30K or 44K bytes. 

By arranging core storage into a number of 
segments or partitions in sizes of 8K or more, 
MFT allows up to 15 user jobs and 39 system 
read and write spooling routines to act simulta¬ 
neously. The maximum number of partitions 
that can be defined is 52; these can service up to 
15 user jobs, 3 readers, and 36 writers. Of the 
52 definable partitions, only 15 may be active 
concurrently. 

Spooled input and output functions place input 
cards onto disc or drum regions as the cards are 
read from card readers for later input to pro¬ 
cessing programs. Output can be printed and 
punched simultaneously with input spooling or 
sent to other direct access areas and printed/ 
punched when the devices become available. In 
this manner, unit-record devices (such as 
printers, punches, and readers) are ’’driven” as 
continuously as possible. 

When the system operator initiates a reader, 
input spooling commences. The operator manu¬ 
ally starts initiators (part of the scheduler) in 
chosen partitions. Jobs are chosen for execution 
in certain partitions by the class job-card param¬ 
eter and executed in order of priority parame¬ 
ters. A partition can execute jobs in more than 
one class — assignment of class to partition is 
performed during system generation time but 
can be modified by the system operator prior to 
execution. A class may be eligible for execution 
in more than one partition. 

Upon completion of a job the scheduler is 
brought into the partition, and another job of 
highest priority and proper class is scheduled 
for execution. If no jobs are available, the par¬ 
tition becomes temporarily dormant. When the 
partition is smaller than the scheduler size, the 
partition becomes quiescent until a large enough 
partition is ready for rescheduling. Then the 
scheduler schedules the larger partition and all 
ready smaller ones. 

Multiprogramming with a Variable Number of 
Tasks 

MVT is the highest level of OS/360. It per¬ 
mits dynamic scheduling of up to 15 programs 
and/or program segments in a true multipro¬ 
gramming environment. Programs are scheduled 
on the basis of priorities established when job 
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definitions are read from the input stream, but 
these priorities can be changed by the problem 
programs during job execution. A program’s 
priority can never be dynamically modified higher 
than its original setting. The system operator 
cannot change program priorities once the pro¬ 
grams have been scheduled for processing. 

The priority scheduler used in MVT is de¬ 
signed to permit flexible and expanded use of the 
multiprogramming capability of the OS/360. Cur¬ 
rently, the number of programs that can be ’’ac¬ 
tive” in the multiprogramming mix at any one 
time is limited to 15. The more common limiting 
factor is the available hardware resources — in¬ 
cluding core storage, auxiliary storage, and con¬ 
ventional I/O equipment. 

This MVT priority scheduler (OS/360 Option 
10) builds a job queue from programs that can be 
continually entered in the input stream. Pro¬ 
grams are then initiated in priority sequence 
whenever sufficient hardware becomes available. 
The scheduler can optionally include the use of 
multiple-program input readers and output writ¬ 
ers that will assist the computer to work in a 
continuous, productive manner. 

Additional functions provided by the priority 
scheduler are: 

• Asynchronous reading and writing of all 
I/O data. 

• Reading and interpreting of control state¬ 
ments that employ all features of the job 
control language. 

• Allocating of I/O devices. 

• Logging of system data. 

• Timing of the execution of program seg¬ 
ments or routines. 

• Interruption of the supervisor if time limits 
are exceeded. 

• Use of alternate console devices in place 
of standard IBM 1052 Printer-Keyboards. 

• Optimization of the use of I/O channels. 

A task directory that describes the use and 
attributes of all current program modules is al¬ 
ways maintained in core storage. Information 
held in the directory can assist in efficient sys¬ 
tem use by enabling one program segment to be 
shared by many jobs. 


Problem programs reside in contiguous blocks 
of core storage dynamically assigned at program 
initiation time. Each program segment (or job 
step) is allocated a 2K-byte block of core stor¬ 
age; additional contiguous blocks are automati¬ 
cally assigned as required. 

MVT furnishes the following additions to PCP: 

• Concurrent control of a variable number of 
tasks. 

• Synchronization of subtasks being executed 
concurrently with a main task. 

• Loading of relocatable programs in non¬ 
contiguous sections of core storage. 

• Asynchronous control of program overlays. 

• Control of multiple transient areas of core 
storage, permitting efficient use of non¬ 
resident control programs. 

• Sharing of active program modules among 
different jobs. 

• Program storage protection. 

• Control of telecommunications access 
methods. 

• System restart control for jobs in the in¬ 
put queue (but inactive) and for output data 
sets not completely transcribed at the time 
of a system shutdown. 

Two miscellaneous though related aspects of 
MVT are the roll-out, roll-in and time slicing 
facilities. Roll-out, roll-in allows temporary dy¬ 
namic expansion of a job, beyond its original 
claim for storage, into assigned regions and then 
into another job’s storage area. The second job 
is ’’rolled out” to secondary storage (disc or 
drum) until enough storage exists as unassigned 
regions to accept the job roll-in. 

The time slicing facility resembles that of 
MFT except that while MFT slices time among 
members of a group of partitions, MVT sets up 
intervals among members of a group of tasks of 
a certain priority. Each member is given control 
of the CPU (’’active” phase) for a certain period 
of time. During this time, normal task dispatch¬ 
ing algorithms hold. 

Additional supervisor functions that have been 
implemented are program checkpoint/re start for 
restarting active jobs, and use of direct access 
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devices for input to a reader interpreter and for 
output from an output writer. 

Time Sharing 

Time sharing capability is permitted with the 
System/360 through use of an extension of OS/ 
360. The extension, called time sharing option 
(TSO), allows conversational creation, syntax 
checking, execution and updating of programs 
and data. 

TSO works under MVT and permits interactive 
operations to run concurrently with batch and 
teleprocessing operations. Up to 14 core regions 
can be dedicated to time sharing. TSO is in¬ 
tended for the Model 50 or larger with a main 
storage of at least 524K bytes. 

LANGUAGE SUPPORT 

Language support consists of Fortran, Cobol, 
and Assembler prompters, which permit those 
compilers to be used in a conversational mode. 
For nonprogrammers, TSO offers code-and-go 
Fortran, and interactive subsets of Basic and 
PL/1. 

FUNCTIONAL CHARACTERISTICS 

Job Types 

Batch (PCP, MFT, MVT), MICH (MFT, 

MVT), data communications (MFT, MVT), time 
sharing, (including conversational) available with 
MVT only. 

Job Scheduling 

PCP: serially; MFT and MVT: job class or 
job class/numeric; equal priority jobs serviced 
FIFO (first in, first out) intraqueue; queues ser¬ 
viced round robin by priority. 

Resource Allocation 

Main Storage: statically assigned, fixed size 
for PCP and MFT partitions; or dynamically as¬ 
signed, fixed size MFT partitions and MVT 
regions. 

CPU Time: variable length time slice accord¬ 
ing to job class (MFT, MVT). 

I/O Devices: statically assigned. 

Information Files: statically or dynamically 
assigned; shareable and nonshareable programs 
and subroutines permitted. 


Program Structure and Loading 

Simply, overlay, and dynamic; relocatable 
programs (overlay and dynamic) compiled at base 
zero and disc address assigned by OS. 

I/O Control 

Device Types: disc, magnetic tape, drums, 
data cells, typewriter, unit record devices, 
graphics (the latter available only with MFT, 
MVT). 

Buffer Allocation: simple, exchange, chained 
segment, and dynamic. 

Remote Terminal Support: remote batch pro¬ 
cessing; standard terminal speed and format. 

Recovery Processing 

Checkpoint all jobs; restart for beginning of 
job or from checkpoint; roll-out, roll-in (MVT 
only); tapes automatically repositioned. 

Diagnostic Error Processing 

Hardware and software errors recognized; 
hardware errors result in error message (stan¬ 
dard), malfunction indication (optional); or ter¬ 
mination of affected task only (optional); minor 
errors retried before termination. Program er¬ 
ror handling routines must be user supplied. 

Processing Support 

Timing Services: interval and real-time. 

Testing and Debugging: snapshot and post¬ 
mortem dumps; routines for testing and debugging 
assembly language programs; routines for testing 
I/O devices, control units and channels. 

Logging and Accounting 

Standard accounting data and hardware error 
statistics kept; no job accounting routines 
provided. 

File Management 

Indexed libraries of macro code, source code, 
relocatable code, executable code; cataloging is 
dynamic. User and system labels identify files. 

File Structure 

Sequential, indexed sequential, partitioned, 
and direct; hierarchical structures permitted. 
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File Storage Allocation 

Auxiliary storage size and density defined by 
user; storage assigned dynamically. 

File Location 

File name and/or user assigned password 
(down to field level) using master catalog; hier¬ 
archical structures permitted. 

File Access Methods 

Sequential, indexed, random, keyed, and 
teleprocessing. 

Job Control Language 

Parameter oriented; consists of the following 
5 classes: 

• Job statement — marks the beginning of and 
identifies a job. 

• EXEC statement — indicates the begi nning 
of a job step (task) and identifies the pro¬ 
gram or catalog procedure to be executed. 

• Data definition (DD) statement — describes 
a data set and requests allocation of I/O 
resources. This statement also binds the 
internal name of a data set (as used in the 
program), or DDNAME, to an external 
name (the physical file name), or DSNAME. 

• Command statement — used to enter com¬ 
mands through the input stream to activate 
or deactivate system I/O units, request 
displays, or perform other operator func¬ 
tions. Commands currently available in tht 
PCP version are: DISPLAY, MOUNT, SET, 
START, STOP, UNLOAD, and VARY. 

More commands are available in the MFT 
and MVT versions of OS/360. 

• Delimiter statement — terminates various 
aspects of the input stream. 

Sorting and Merging 

The sort/merge programs are part of the op¬ 
erating system and operate under its control. 

Like the operating system itself, the sort/merge 
programs can be tailored to the needs of the in¬ 
stallation at SYSGEN time. 

The sort/merge programs sequence the logi¬ 
cal records of a data set according to the con¬ 
tents of a control word. A control word is user 


defined and can contain 256 bytes of information 
and up to 64 control fields. The programs sort 
a data set of an unknown order into a predesig¬ 
nated order and merge up to 16 previously sorted 
data sets into a single sorted data set. 

The programs operate with any level of the 
operating system and require 15,500 bytes of 
main storage. Of this, 12K bytes are needed for 
the sort/merge programs themselves, while the 
remaining 3,500 bytes are used for system func¬ 
tions. One selector or one multiplexor channel 
is needed, as well as one disc. 

DESCRIPTION AND EVALUATION 

If you subscribe to the theory that an operating 
system should allow the user to be almost totally 
ignorant of the system 1 s operational character¬ 
istics, and allow him to default his way through 
jobs while maintaining some semblance of effi¬ 
ciency, then you’ll probably have trouble with 
OS. This system is not for amateurs or the lazy. 

OS/360 is both complex and sophisticated — 
perhaps too sophisticated for a large portion of 
the data processing community to use effectively. 
Users, for example, must tailor the operating 
system to fit their processing needs by ’’spelling 
out, ” via a procedure called system generation 
(SYSGEN), the components required and their 
interfaces. Problem programs must be designed 
and scheduled to make optimum use of these fa¬ 
cilities, and communication between scheduling 
components of the operating system and the prob¬ 
lem program must be set up via the somewhat 
complex job control language. If all is handled 
properly, OS/360 performs well. It’s the ”if 
nots” that cause the waste and the wails. 

The following contains a description and eval¬ 
uation of some of the more important features of 
OS/360. 

Job Scheduling 

Jobs entering the system are scheduled for 
execution on either a sequential or user-assigned 
priority basis. Priorities permitted are by job 
class, or by numeric, or by a combination of the 
two. 

Under MFT, incoming jobs are taken directly 
from the input stream and enqueued directly in 1 
of 15 available job queues, corresponding to a job 
class parameter specified by a job control state¬ 
ment. The job statement identifies the job and 
contains user-specified priority data (if appli¬ 
cable) plus some accounting information. 
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If priority schedulers are used, job class in¬ 
formation can also be assigned to jobs. The 
class assignment determines where the job is 
placed in its respective queue; the priority pa¬ 
rameter determines the job T s initiative priority 
within its job class. Jobs of equal priority are 
enqueued on a FIFO basis. 

Up to 15 jobs can compete for resources con¬ 
currently under MVT and MFT. Each job is se¬ 
lected for execution from an input queue accord¬ 
ing to its priority within a class. Each step of 
each job is executed sequentially. A region 
(MVT) or partition (MFT) is a single, contiguous 
block of core; 15 regions or partitions of main 
storage can be assigned to processing programs 
at any one time. 

Scheduling of all jobs under MFT is handled by 
a single job initiator, which may be transient or 
permanently resident in a partition. The initiator 
comes in 2 sizes: 30K bytes and 44K bytes (the 
larger is recommended where job duration is 
short or turnaround is high). Since only one ini¬ 
tiator is available, contention for its services is 
unavoidable thus resulting in some processing 
delays. 

Up to 52 fixed memory partitions can be spec¬ 
ified by the user for MFT. (These include the 
15 job partitions plus 3 input readers and 36 out¬ 
put writers.) Each can service up to 3 queues. 
Priority among queues for each partition is 
based on the order in which they were originally 
defined, that is, higher-priority queues are ser¬ 
viced before lower-priority queues. 

Job Initiation. Under MVT, jobs are not ex¬ 
ecuted as encountered in the input stream. 

Rather, a job T s control information is entered in 
an input work queue corresponding to the job T s 
class. Fifteen work queues are available, and 
the initiation of a job within a queue is deter¬ 
mined by the priority within the class. Use of 
work queues as opposed to job queues reaps 
some significant benefits over MFT. For ex¬ 
ample, each queue can be fed by more than one 
input stream, thus permitting the system to 
handle different job classes and priorities within 
the class. This priority can then be applied to 
the tasks themselves and used to resolve con¬ 
tention for system resources. 

A job’s class and priority are specified by the 
user when the job is submitted. The operator, 
however, can modify a priority up to the time 
the job is actually selected for execution. If sub¬ 
tasking* is employed in either MFT or MVT, the 

* A subtask is a task created by a job step 

during its execution. 


system establishes 2 other priorities automati¬ 
cally — dispatching priority and limit priority. 
(Both are determined by the job priority within a 
class.) The dispatching priority is used by the 
resources manager to resolve requests for main 
storage and CPU resources; the limit priority 
controls dynamic priority assignments. Either 
can be changed by the operator during program 
executions. 

A job is initiated under MFT and MVT by an 
initiator routine assigned to handle a specific job 
class. The initiator selects a job from the job 
class and schedules it for execution only if all 
files or data sets, sufficient contiguous core, and 
all I/O devices it requires, are available. If not, 
either the initiator waits for the resources to be¬ 
come available, or the job is canceled and the next 
job in that class is initialized, and so forth, until 
every job in that class is serviced round robin. 

Jobs are processed in a series of tasks. The 
state of a task depends on its readiness to use the 
CPU. If it can make immediate use of the CPU, 
it’s in the ready state. If using the CPU, it’s in 
the active state. Otherwise the task is waiting. 
Once a task is active, it runs to completion un¬ 
less interrupted. The interrupted task regains 
control only if all other ready tasks are of an 
equal or lower priority. 

Program-initiated scheduling (otherwise known 
as dynamic link loading) is available under MVT. 
In this case a program executes a request to the 
supervisor to attach another task. The supervi¬ 
sor then creates a new task and schedules its ex¬ 
ecution. This new task is actually a subtask to the 
original task and may have a different priority. 

Job steps within a single job are performed in 
sequential order. The system also provides for 
conditional execution of subsequent job steps, de¬ 
pending on completion of the previous one. A step 
being executed can communicate with succeeding 
steps in the same job through condition codes and 
passed data sets. It cannot pass data to succeed¬ 
ing steps by leaving such data in its memory 
region or partition; consequently, registers must 
be used to handle this function. 

Scheduling Considerations . The use of both 
job class and numeric — or a combination of 
both — is quite good, for it ensures that the im¬ 
portant jobs can be placed in a higher priority 
queue and assigned a high numeric priority within 
the queue. 

A job’s priority class and its position within 
its queue, however, are no guarantee the job will 
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be scheduled immediately. Generally, under 
OS/360 no job is scheduled for execution unless 
all files or data sets, sufficient contiguous core, 
and all I/O devices it requires are available. 

Whether this lockout degrades overall perfor¬ 
mance, of course, depends on your processing 
requirements. However, we feel that any sys¬ 
tem with a dual priority scheme should have a 
provision for assigning a processing priority for 
automatically interrupting lower-priority jobs 
currently processing and reallocating their re¬ 
sources to higher-priority jobs. 

Preparing an optimum job mix is far more 
critical with OS/360 than with systems that dy¬ 
namically adjust resources and reschedule jobs 
to meet processing needs. Without a careful mix, 
jobs are delayed and system resources wasted. 

The underlying technical problem with OS/360 
that makes job scheduling critical is that the sys¬ 
tem is incapable of determining if sufficient re¬ 
sources will be available to finish a job once it 
begins. In a multiprogramming environment, for 
example, all jobs of equal priority compete for 
resources on an equal footing. The first job to 
gain control holds it. In the meanwhile, jobs 
which could be using needlessly held resources 
must wait until the owner job releases them; 
hence, the processing delays. 

Resource Allocation 

Internal storage and CPU control are assigned 
to tasks according to their priorities. The super¬ 
visor controls and allocates storage space dy¬ 
namically, i.e., when requested by a task or the 
control program. It also supervises the alloca¬ 
tion of other resources, keeps track of all assign¬ 
ments, and frees resources upon task completion. 

If more than one task in a multitasking envi¬ 
ronment is contending for the same resources 
simultaneously, requests are queued. When the 
resource becomes available it is given to the 
ranking member of the queue. To keep track of 
assignments, the system maintains tables indi¬ 
cating unsatisfied requests and available 
resources. 

Main Storage . A job’s internal storage can be 
specified for each job step or the entire job, and 
requested either explicitly (MVT, MFT) or im¬ 
plicitly (MVT); the latter is used when a program 
must be entered from a library. Generally a 
fixed amount of storage is allocated to each job 
or job step. 

The supervisor controls and allocates core 
storage dynamically from a pool; under MVT, 


areas of storage can be passed or shared be¬ 
tween tasks. Subpools of 2K-byte blocks are 
allocated for a particular task operating under 
one label with attached tasks. Such subpools are 
available to attached tasks and can be released 
or maintained when the attached task terminates. 

Main storage is protected in blocks of 2K bytes: 
each block is assigned a storage protection key. 
The supervisor is assigned key 0 and keys 1 
through 15 are assigned to jobs. Each task in a 
job operates under an assigned job key. 

If processing requires additional core, it can 
be obtained under MVT by employing a feature 
that allows job roll-in, roll-out. Roll-in, roll¬ 
out is invoked by the operator and allows the tem¬ 
porary, dynamic expansion of a particular job be¬ 
yond its originally specified region. 

When a job needs more contiguous storage, 
roll-in, roll-out attempts to obtain it from un¬ 
assigned storage. If this is impossible, another 
job is rolled out to disc and its vacated region is 
assigned to the requesting job. At the job’s com¬ 
pletion, the appropriated storage is either re¬ 
turned to the interrupted job or placed in the un¬ 
assigned storage pool. A roll-in, roll-out always 
triggers the checkpoint/restart facility of the 
system. 

OS/360 critics are quick to point out, and right¬ 
ly so, that the system cannot handle core-frag¬ 
mentation . This condition occurs when process¬ 
ing programs vacate core, and the contiguous 
area available to waiting programs are in¬ 
sufficient to handle them. Core then remains 
unused, resulting in a condition called core 
’’checkerboarding." 

Some systems have solved checkerboarding by 
dynamically rearranging currently processing 
jobs to fill the vacant areas, thus creating con¬ 
tiguous available core in those places previously 
occupied. (This feature has been jargonistically 
dubbed ’’garbage collection. ”) OS/360 has no 
such capability. To clean up a checkerboard, the 
OS/360 user must re-IPL. To guard against 
checkerboarding, the user must schedule jobs 
carefully, or operators must continuously moni¬ 
tor running jobs and cancel those that might 
cause checkerboarding. (Such jobs are generally 
compute-bound ’’core eaters, ” which leave large 
unusable holes due to their position in core.) 

Core Buffers . Core buffers can be obtained 
in S ways: they can be defined at assembly time; 
they can be acquired during execution by a mac¬ 
roinstruction; or they can be acquired by default 
when opening a file. The default method does not 
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require the buffer for each input request prior to 
execution. Instead a buffer is taken from a pool 
and assigned immediately before data transfer 
begins. The buffer remains in use and can be 
dynamically assigned to another active request; 
it is returned to the buffer pool automatically 
when not needed. 

I/O Devices. I/O devices are allocated at the 
beginning of the job, unless they are specifically 
deferred (through JCL) until an OPEN is issued 
for the file. If these devices are unavailable, the 
job is not scheduled until they are. Devices can 
be allocated by physical device category (sequen¬ 
tial or direct access). Operators can place I/O 
devices on- or off-line via terminal commands, 
and on certain models of the 360 designate cer¬ 
tain hardware as unusable due to a malfunction. 

CPU Time. Time slicing is employed in mul¬ 
tiprogramming (and multiprocessing) to ensure 
that all actively processing jobs have an oppor¬ 
tunity to use the CPU. In some systems the 
length of the time slice is standard for every 
job, regardless of priority, while others allow 
the user to vary the slice duration assigned to 
jobs. OS/360 uses the latter technique, and it is 
excellent. By employing variable time slices, a 
smart user can arrange his short and long turn¬ 
around jobs in a manner that ensures maximum 
throughput. 


Shared Files . Multiprogramming requires the 
use of various files and data sets, many of which 
are common to several problem programs. To 
eliminate redundancy and the expense of mainte¬ 
nance, IBM offers a shared direct access de¬ 
vice option for use on all versions of the oper¬ 
ating system including PCP. 

With the shared direct access option, common 
files or data sets are placed on disc, and all 
problem programs have access to them. A pro¬ 
gram can lock a disc track during both reading 
and updating operations. 

System Support Facilities 

Facilities offered to aid system managers in 
monitoring and evaluating system performance 
are very good. Programs are available for 
monitoring usage of CPU, I/O devices, and stor¬ 
age in an attempt to identify job bottlenecks. Vol¬ 
ume statistics routines record errors that are 
due to deteriorating magnetic tape. However, 

IBM offers no routines which test if hardware 
components are going "soft" (i.e., beginning to 
fail), so that actions could be taken to safeguard 
data before a hard failure occurs. 

HEADQUARTERS 

International Business Machines Corporation 

1133 Westchester Avenue 

White Plains, NY 10604 
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GENERAL 

DOS is a comprehensive set of language trans¬ 
lators and service programs designed to furnish 
small- to medium-scale System/360 and 370 
computer systems (System/360 Models 30, 40, 

50 and their System/370 counterparts) with mul¬ 
tiprogramming and telecommunications control. 

It is highly modular and can be generated with 
widely varying configurations, depending upon 
the control functions required in specific instal¬ 
lations. It can be expanded to service the needs 
of all of an installation’s applications programs 
or tailored to a minimum system to control the 
operation of a single program. DOS supports an 
interval timer, up to 6 multiplexor channels, the 
2816 Tape Switching Unit, and up to 16,777,216 
bytes of core storage. 

Four processing versions of DOS can be 
configured: 

• Serial batch processing. 

• Fixed partition multiprogramming with 1 
background batch processing stack running 
concurrently with 2 operator-initiated 
foreground jobs. 

• Batch job foreground processing with 1 
background and 1 foreground batch pro¬ 
cessing stack both running concurrently, 
and 1 operator-initiated foreground job. 

• Multiprogramming of 3 batched job stacks. 

The processing programs provided and con¬ 
trolled by DOS include routines for telecommuni¬ 
cations processing, language translators, ser¬ 
vice programs, and the user’s own problem 
programs. Programs in 5 different languages 
can be translated into relocatable object mod¬ 
ules. The 5 languages available are Assembler, 
Cobol, Fortran, PL/l, and RPG. 

Users have the option of constructing pro¬ 
grams as either simple structures, planned 
overlay structures, or dynamic structures. 


The simple structure is a self-contained pro¬ 
gram, calling no other programs during execu¬ 
tion. Planned overlay consists of a number of 
subprograms, containing a root segment that is 
always core resident during execution and over- 
layable segments that are called as needed. All 
subprograms are loaded and executed serially. 
The dynamic structure consists of subprograms 
executed serially, with resources called when 
necessary. 

The program steps required to produce a pro- 
cessable program are shown in Figure 1. 

Object modules produced by the compiler or 
assembler can be link edited immediately, or 
they can be stored in a relocatable object pro¬ 
gram module and link edited later. The output 
of the linkage editor consists of one or more 
program phases. Before execution, in either 
case, all programs must be loaded into a core 
image library or link-and-execute file after link 
editing. 

Each system residence device contains 1 to 3 
types of libraries: core image (required), relo¬ 
catable, and source statement. Each library is 
preceded by a directory. 

The core image library contains IBM-supplied 
programs and user programs. Each program 
consists of one or more phases created by the 
linkage editor, thus allowing a phase to be a sin¬ 
gle program or an overlay. (The latter applies 
to multiphase programs.) User programs 
link edited to the core image library are 
nonrelocatable. 

The relocatable library contains object 
modules that can be executed from any storage 
location. When link editing is performed, these 
modules can be combined with other program 
modules. Hence, frequently used routines can 
be kept in residence and included in any phase 
when needed, without recompiling or reassem¬ 
bling them. 



Figure 1. IBM DOS: Program Development Stages 
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The source statement library, for the most 
part, extends the functions of a macro code li¬ 
brary and contains sequences of source language 
statements. These sequences are called books, 
and only complete books (not individual records) 
can be added to or deleted from the library. 

Both the librarian and linkage editor support 
the libraries. The Librarian consists of a group 
of routines that maintain and service the li¬ 
braries. Maintenance routines, for example, 
allowing adding, deleting, and copying items to 
and from the library. 

The linkage editor service program is one of 
the critical components of the DOS. Ail pro¬ 
grams executed under DOS must be edited by the 
linkage editor before execution is possible. The 
program combines object modules supplied in the 
job input stream, newly compiled object mod¬ 
ules, and object modules from the relocatable li¬ 
brary. It edits the modules into executable pro¬ 
grams. These programs then can be fetched 
directly from the link-and-execute file (a tem¬ 
porary part of the core image library) or they 
can be cataloged into the core image library. 

All programs except self-relocating assembly 
language routines must be link edited for each 
change of core configuration. 

Execution of programs under DOS is a 3- 
phase process including compilation by a lan¬ 
guage processor, linkage editor functions, and 
loading of the program phase (s) by the system 
loader. 

The output of the linkage editor, called a pro¬ 
gram phase, is that section of a program which 
is loaded as a single overlay with a single FETCH 
or LOAD by the system loader. Programs can 
consist of many phases, the first fetched by job 
control and each of the following by a preceding 
program phase. Successive phases of a multi¬ 
phase program are called overlays. 

DOS is supplied in the form of 3 libraries; 
these contain the supervisor, language transla¬ 
tors, and all necessary service and utility pro¬ 
grams and routines. The system, as received 
from IBM, is ready for immediate operation. 
Most users, however, tailor the supervisor to 
fit their individual configurations and edit the 
system libraries to meet their particular needs. 

Operating Environment 

Minimum system facility needs vary with the 
application. Batch processing requires at least 
16K bytes of core storage and one 2311 Disc 
Storage Drive or one 2319 Direct Access Facility 


as auxiliary storage for System/360. For Sys¬ 
tem/370 minimum batch processing requires a 
2311, 2314/2319, or 3330 disc and 24K bytes of 
main storage (which is less than the minimum 
purchasable System/370 main storage). Using 
the DOS multiprogramming supervisor to execute 
a batched job in the background partition and lor 
2 foreground programs raises the core storage 
requirement to 24K bytes, as does the use of 
DOS Cobol or telecommunications control. Mul¬ 
tiprogramming with a single batched job in the 
foreground partition requires 32K bytes of core 
storage, and multiprogramming with batched 
jobs in both foreground areas requires a mini¬ 
mum of 65K bytes of core storage. 

FUNCTIONAL CHARACTERISTICS 

Job Types 

Batch and teleprocessing. 

Job Scheduling 

Serially by partition; jobs serviced first in, 
first out (FIFO); priority scheduling permitted 
with optional POWER spooler. 

Resource Allocation 

Main Storage: fixed size partitions. 

CPU Time: indefinite time assignment. 

I/O Devices: statically assigned to partition 
or unassigned at SYSGEN. 

Information Files: statically assigned; read/ 
write-only access; nonreusable, serially reus¬ 
able, relocatable. 

Program Structure and Loading 

Simple structures, planned overlay, or dy¬ 
namic structures; object modules link edited 
immediately or stored in relocatable module li¬ 
brary for link editing later. 

I/O Control 

Device Types: disc, magnetic tape, type¬ 
writer, unit record devices. 

Buffer Allocation: user specifies single, 
double, or exchange. 

Remote Terminal Support: standard terminal 
speed and format; supports basic terminal ac¬ 
cess method (BTAM), queued terminal access 
method (QTAM), and conversational mode 
(optional). 
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Recovery Processing 

Checkpoint entire partition; restart from 
checkpoint limited to batch jobs only. Sequential 
and direct access devices repositioned but not 
I/O stream or unit record devices. 

Diagnostic Error Processing 

Hardware and program errors recognized and 
serviced; hardware error trace routines and 
hardware validity test supplied; symbolic de¬ 
bugging for assembly language programs 
provided. 

Processing Support 

Timing Services: real-time clock. 

Testing and Debugging: postmortem and 
snapshot dumps; symbolic debugging for assem¬ 
bly language programs in background mode. 

Logging and Accounting 

Standard accounting data; no accounting rou¬ 
tines provided; hardware error statistics kept. 

File Management 

Standard, user-defined, and nonstandard la¬ 
bels accepted; no file or volume system indexes 
permitted. 

File Structure 

Sequential and indexed. 

File Storage Allocation 

Auxiliary storage size and density defined by 
user. 

File Location 

User-defined file name and specific data set 
extents (direct access) and/or device address 
(magnetic tape, unit record, and so forth); hierar¬ 
chical structures permitted. 

File Access Methods 

Sequential, indexed sequential, partitioned, 
and direct. 

Job Control Language 

Verb oriented. The statements describe each 
job step to be executed. The allowable options 
and specific identifications are described in the 


operation portion of the statement rather than 
as parameters within the statement (as in OS/ 
360). 

Among the frequently used statements within 
the DOS JCL are those for identifying a job to 
the system, binding a symbolic name to a phys¬ 
ical I/O device, providing a date for the job being 
executed, initiating execution of a task (job 
step), establishing program options, printing an 
1/O assignment list, providing volume and file 
label information, indicating limits of a direct 
access file, and identifying and locating check¬ 
point records for starting or restarting a job. 

Sorting and Merging 

The sort and merge program is part of the 
operating system and lets the user sort multiple 
files or randomly ordered records or merge 
files of sequenced records into one sequential file. 
Up to nine input files can be sorted and eight in¬ 
put files merged. 

Sequencing is performed by comparing a 
maximum of 12 specified control fields within the 
records. The programs assume random se¬ 
quences for input files to sort operations but take 
advantage of any inherent ordering. Records 
can be sorted or merged by control field in as¬ 
cending or descending order. 

DESCRIPTION AND EVALUATION 

Like OS, DOS is competent provided the user 
is familiar with its operating characteristics and 
schedules his work intelligently. Otherwise, as 
the following comments point out, many system 
resources will be wasted and job throughput will 
be significantly reduced. 

Job Scheduling 

Job scheduling, as it relates to efficient 
throughput, is extremely important under DOS 
due to the way job queuing and priority process¬ 
ing interrupts are handled. 

Jobs submitted for processing are taken di¬ 
rectly from the input stream and executed seri¬ 
ally, or they are entered singly by the operator 
and processed as received. * No job queuing as 
such is used, nor is program size considered. 
The priority scheduling scheme is by job class 
only, with jobs batched or individually submitted 


* Job queuing and priority scheduling are per¬ 
mitted if the optional POWER spooling routine 
is used. 
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to designated partitions. DOS permits 1 back¬ 
ground and 2 foreground partitions to be estab¬ 
lished: foreground-one has the highest priority, 
foreground-two the next highest, and the back¬ 
ground partition the lowest. 

There are, of course, tradeoffs in using the 
DOS scheduling method. No system overhead is 
incurred in maintaining job queues and no facili¬ 
ties are needed which automatically roll jobs in 
and out of core to satisfy high-priority job inter¬ 
rupts. On the other hand, such interrupts invari¬ 
ably occur during processing and thus must be 
handled by the operator. 

It is the operator’s responsibility to suspend 
or cancel a processing job to permit entry of the 
higher-priority job and in some cases change the 
size of the partitions to meet core needs. The 
later operation may require cancellation of all 
processing jobs if the interrupting job is very 
large. These operations may also be necessary 
when a job terminates normally and the next 
waiting job is too large to fit in the available par¬ 
tition. The net result in either case is a de¬ 
crease in overall job throughput, which, in all 
instances except those dealing with the highest- 
priority jobs, can be avoided by careful job 
scheduling on the part of the user. 

Each processing program occupies contiguous 
areas of main core. To operate in a multipro¬ 
gramming mode, a minimum of 24K bytes of 
main core is needed. Ordinary batch processing 
requires at least 10K bytes of core. 

Multiprogramming . There are 2 types of 
problem programs in DOS multiprogramming: 
background and foreground. These programs 
initiate and terminate asynchronously from each 
other and are logically independent. 

Under DOS, the background partition generally 
processes batched jobs, which are initiated in 
the sequence in which they appear in the batched 
job input stream. The foreground programs run 
in their respective partitions and are initiated by 
direct commands from the operator. 

Single programs destined for a foreground 
partition are scheduled by the foreground initia¬ 
tion program routine — also called the single 
program initiator (SPI). The operator invokes 
this routine via the printer-keyboard or opera- 
tor-assigned card reader; SPI requires 2K bytes 
of main core. Foreground programs can ex¬ 
ecute in batch job foreground (BJF) mode pro¬ 
vided the 10K bytes of main core (needed for the 
job control statement processor) are available 
and separate system I/O files are dedicated to 
the partition. 


When batch processing is specified for the 
foreground area, a communication region is au¬ 
tomatically established in that partition. Al¬ 
though all system logical units can be used by 
either foreground or background programs, fore¬ 
ground programs executing in SPI mode can have 
only card readers, card punches, and printers 
assigned to them. 

Batch job multiprogramming (all partitions 
running in the batched job mode) requires that 
every program operating in each partition be link 
edited either to the system core image library 
or a private core image library, depending on 
where the link editing occurs. If link edited in 
the background partition, the system library can 
be used; if link edited in the foreground, a pri¬ 
vate library is required. 

Programs slated for execution are generally 
held in 1 of 3 available system libraries, viz., 
relocatable program library, core image li¬ 
brary, or source library. These libraries are 
established from the object modules produced by 
the system language translator. Although pro¬ 
grams are in relocatable format in the relocat¬ 
able program library, they must be link edited 
before execution. Normally, background mod¬ 
ules are absolute (i.e., not relocatable); fore¬ 
ground modules, however, must be self-relocat¬ 
ing and, if in a core image library, can operate 
in foreground and background partitions. Once a 
relocatable module is link edited, it is in an ab¬ 
solute executable format; thus additional copies 
of the program must be kept if it is to run in 
more than one partition. 

A core image library contains any number of 
programs, each comprising one or more pro¬ 
gram phases created by the linkage editor. Each 
phase can be a single program or, in the case of 
a multiphase program, an overlay. 

Multitasking . IBM claims that multiprogram¬ 
ming can be performed within a partition. We 
feel this capability would be more accurately de¬ 
scribed as multitasking. 

Multitasking within all partitions is supported 
for assembler language programs only. To per¬ 
form such multitasking each program must be 
divided into main tasks and associated subtasks. 
Each subtask shares the same partition with and 
is initiated by its main task. Processing priori¬ 
ties are assigned subtasks according to the order 
in which they are entered, with the first receiv¬ 
ing the highest. During execution, a subtask has 
a higher priority than the main task. 

Up to 9 subtasks can be attached to a main 
task within a partition. Alternately, subtasks 
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can be attached to main tasks in more than 1 
partition, provided the total number of subtasks 
does not exceed 9. The main task, however, 
must initiate execution of the subtasks which then 
execute in a single-thread, dependent state. 

Program States . Processable problem pro¬ 
grams are always in 1 of 3 states: active, 
ready, or wait. An active program is one that 
currently has control of the CPU; a ready pro¬ 
gram is one that has all its required system re¬ 
sources available and is awaiting its turn for the 
CPU; a program in the wait state is awaiting the 
completion of some event such as an I/O 
operation. 

With the exception of 1/O and external inter¬ 
rupts, all programs operate with interrupts per¬ 
mitted (no masking is allowed), which is unfortu¬ 
nate. Consequently, when an interrupt occurs, 
the supervisor gains control and immediately 
handles it. In some cases this can cause unac¬ 
ceptable — and unnecessary— processing delays. 
Control is taken from a high-priority program 
when it encounters a condition that prevents con¬ 
tinued processing until a specified event has oc¬ 
curred. Control is taken from a lower-priority 
job when an event for which a higher-priority job 
was waiting has been completed. 

Processing Limitations . There are limita¬ 
tions as to the types of programs that can be run 
in the background and foreground partitions. 
Fortran, PL/l (D-level), Assembler, Cobol, 
and RPG can be run as batched job foreground or 
background programs. Programs produced by 
the Fortran, Basic Fortran, and PL/l compilers, 
however, will not be run as single program ini¬ 
tiator foreground programs because they require 
access to a communication region. Assembler 
and RPG programs can run a single program ini¬ 
tiator foreground program provided no access 
to a communication region is required. 

Cobol programs run without restrictions in an 
SPI foreground environment. In a multiprogram¬ 
ming environment, telecommunication programs 
are normally run in the foreground-one area be¬ 
cause that area is assigned the highest priority 
of the three program areas. 

Most IBM-supplied software runs only in the 
background partition. If the batched job fore¬ 
ground option is used, however, the linkage 
editor, certain library functions, and the sort/ 
merge program can be operated foreground or 
background. 

DOS provides no symbiont routines or inter¬ 
mediate files as standard facilities for input or 
output data; rather, the I/O device reads and 


writes are performed on-line. Absence of these 
support features is a notable detraction, for with¬ 
out them the system is greatly limited in its ca¬ 
pability to handle multiprogramming. If users 
wish such symbiont services, they are available 
via the optional POWER spooling package. 

Symbiont programs and intermediate files al¬ 
low I/O devices to operate at their fullest data 
transfer rates and permit programs to process 
1/O stream data at storage file transfer speeds 
rather than at the lower peripheral device speeds. 
Thus throughput is increased without adding ad¬ 
ditional peripherals. By not employing them, 

DOS loses somewhat on input; output losses, 
however, are significant, particularly if only one 
output device is being used and more than one 
program is competing for it simultaneously. 

Resource Allocation 

The size of each memory partition is estab¬ 
lished at SYSGEN but can be modified by the op¬ 
erator to meet changing processing require¬ 
ments. This type of modification, however, re¬ 
quires that each affected partition be inactive (no 
programs processing), which usually means sus¬ 
pending operating jobs in more than one partition, 
in turn reducing overall throughput. 

The core allocated to each partition is fixed, 
and the program operating within a partition re¬ 
ceives all the core allocated to it. The inherent 
drawback with this scheme is that poor planning 
in establishing partition size versus program 
needs can waste core if the program is too small 
or decrease throughput if repartitioning is needed 
for programs that are too large to fit. 

A storage protect capability, prohibiting pro¬ 
grams not assigned to a partition from writing in¬ 
to or directing an I/O operation into another par¬ 
tition or the supervisor area, itself, is offered 
as an option. The protection feature is manda¬ 
tory to handle multiprogramming. 

1/O devices are normally allocated permanent¬ 
ly to the partition, temporarily to the job, or are 
unassigned. The operator, however, can per¬ 
manently or temporarily modify device assign¬ 
ments when the system is initialized or when it 
is between job steps. At the conclusion of each 
job requiring a resource modification, job con¬ 
trol restores all temporary assignments to the 
SYSGEN condition. 

Device assignments are made via assignment 
cards in the job control stream (background jobs) 
and via operator console commands for fore¬ 
ground jobs. Devices can be shared among sub¬ 
tasks within a partition, or in selected cases be¬ 
tween background and foreground tasks. 
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In assigning a direct access device, an abso¬ 
lute channel and unit address must be specified 
along with requirements for label and extent in¬ 
formation. The operator must also ensure no 
other partition is currently referencing the file 
specified by the related extent information. 

The actual device assignment can be made in 
the source program using the physical device 
name, symbolic name, or symbolic address. De¬ 
vice name and symbolic address assignments are 
unadvisable, in our opinion, due to the variation 
of such names and addresses between and within 
installations. To combat the ambiguity of device 
addresses and names, a standard set of symbolic 
names has been established by IBM. Each rele¬ 
vant name is associated with an I/O device before 
the execution of a given program. This procedure 
is performed by the program initiator, based on 
operator commands or control statements. 

The input/output control system (IOCS) em¬ 
ployed by DOS consists of reentrant routines im¬ 
bedded within the supervisor and serially reus¬ 
able routines loaded into a transient area. These 
routines, which may be accessed by either fore¬ 
ground or background programs, initiate or test 
I/O operations and supervise the execution of 
channel programs. 

File Handling 

Unfortunately, DOS does not permit system 
cataloging of file and volume indexes. There¬ 
fore, a sequential volume label comparison must 
be performed against each on-line volume until 
the desired volume and file are located — a 
rather time-consuming and resource-wasting 
procedure. In addition, the absence of system 
indexes means there is no capability to locate an 
off-line file; instead the operator must present it 
to the system. 

Processing Support 

Facilities exist within the supervisor to pro¬ 
vide intermediate as well as terminal core 
dumps. Intermediate core dumps are for the to¬ 
tal user partition or for selected areas. No 
tracing facilities exist within the supervisor. 

Abnormal end-of-job conditions always result 
in the termination of all subsequent steps within 
that job. Consequently, file dumps desired for 
abnormal terminations must be scheduled as a 
separate job. 


DOS also provides a set of programs for test¬ 
ing I/O units. Tests can be run to diagnose I/O 
errors, verify repairs, verify engineering 
changes, or just to periodically check the devices. 

A debugging facility is offered for assembly 
language programs operating in the background 
mode. Called Autotest, it is particularly useful 
for symbolic debugging of assembled decks. Au¬ 
totest is a job step; i.e., it is part of a larger job 
that might include assembling, link editing (done 
by Autotest), and execution — all monitored by 
this test program. 

With Autotest, instructions can be exchanged, 
added, or deleted without reassembling or com¬ 
puting linkage addresses. Data can also be dis¬ 
played from selected areas of main storage and 
printed at specified points during program 
execution. 

Support Utilities 

Most of the DOS support utilities are problem 
determination tools, which recommend a specific 
procedure to be followed when a condition such 
as an I/O error or CPU failure occurs. One 
group of programs, however, is offered for er¬ 
ror analysis. Called Problem Determination 
Serviceability Aid (PDAID), it allows users to 
trace the following events: fetching or loading 
of other programs; I/O activity; supervisor calls, 
that is, the communications between the control 
problem and the problem program; and QTAM 
I/O activity. Tracing consists of recording per¬ 
tinent data for user analysis. 

DOS also offers a system volume statistics 
option that records errors originating from tape 
or discs. (Such errors are generally caused by 
contamination or oxide coatings on the recording 
surfaces.) Through cognizance of these errors, 
the user can act before the file data is destroyed. 

Job accounting routines are not supplied by 
IBM for DOS. This valuable utility must be user 
supplied. However, a job accounting log is pro¬ 
vided for input to the user’s routines and con¬ 
tains the job number and the time a job or job 
step uses. 

HEADQUARTERS 

International Business Machines Corporation 

1133 Westchester Avenue 

White Plains, NY 10604 
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GENERAL 

Operating System/370 Virtual Storage 1 and 2 
(OS/VS1 and 2) are functional extensions of OS/ 
MFT and MVT, respectively, and are intended 
for use with System/370 Models 135 (VS1 only) 
upward to Model 168 (including MP version) but 
not Models 155 or 165* Although VS1 will run on 
a system with as little as 128K bytes of real stor¬ 
age, a more realistic minimum is 240K bytes. 

VS2 will run on as little as 384K, but between 
512K and 1,024K bytes is more realistic (depend¬ 
ing on options used). 

In all, the differences between VS1 and 2 and 
their nonvirtual counterparts deal with improved 
management of peripheral I/O operations, im¬ 
proved remote job entry, and improved job ini¬ 
tiation. The most notable difference, of course, 
is the support of a partitioned single virtual stor¬ 
age of up to 16 million bytes divided into 64K- 
byte segments. 

Processing programs provided include a sys¬ 
tem assembler that supports all the new System/ 
370 instructions, a new data accessing method 
called VSAM, a new job entry system called JES 
(VS1 only), and a new linkage editor. The same 
utilities (with some modifications) as used with 
standard OS/M FT and MVT are still employed. 
The new systems also provide such recovery 
management programs as OLTEP and Service 
Aids, as well as the same integrated emulator 
advantages of OS/M FT and MVT. 

OS/VS1 and 2 are not entirely new operating 
systems, but rather are enhanced versions of 
their nonvirtual parents. (In fact, they’ve been 
called MFT and MVT with paging — which is not 
entirely accurate.) As such, they retain many old 
features. The following paragraphs point out the 
enhancements and differences between VS1 and 
MFT, VS2 and MVT, and VS1 and VS2. Following 
them is an elaboration on the principal features 
found in both systems. Since most of the changes 
affect VS1, most of this report deals with that 
operating system. 

OPERATING SYSTEM DIFFERENCES 

OS/VS1 and OS/MFT 

OS/VS1 is a functional extension of OS/MFT. 

Of the many new features of OS/VS1, 4 are of 
particular note. 

• Support of a partitioned single virtual stor¬ 
age of up to 16 million bytes divided into 
64K-byte segments (on external page store) 
and 2K-byte pages. 


• Improved management of peripheral I/O 
operations. 

• Improved remote job entry. 

• Dynamic job dispatching. 

Processing programs provided include a sys¬ 
tem assembler, which supports all the new Sys¬ 
tem/370 instructions, a new data accessing 
method called VSAM, a linkage editor, and the 
same utilities (with some modifications) as those 
provided with standard OS/MFT. The new sys¬ 
tem also provides such recovery management 
programs as OLTEP and Service Aids, as well 
as the same integrated emulator advantages of 
OS/MFT. 

OS/MFT programs and data will operate with¬ 
out change under VS1 with few exceptions (those 
sensitive to the PSW, for example). DOS Version 
3 and 4 users can make the transition to VS1 with 
the OS/DOS emulator. 

MFT features not supported in VS1 are Tes- 
tran, old remote job entry, graphic job processor, 
satellite graphic job processor, storage hierarchy 
support (unnecessary with virtual memory), and 
QTAM. The latter is replaced by TCAM. 

Dynamic dispatching is a new feature of the 
task supervisor included in the system when the 
automatic priority group (APG) option is se¬ 
lected. Installation-designated groups of tasks 
are dispatched based on their operational charac¬ 
teristics: CPU-oriented or I/O-oriented. CPU 
and I/O characteristics of the group of tasks are 
constantly monitored during their execution and 
changes are taken into account in the dispatching 
process. 

VS1 and VS2 select low priority jobs and move 
their pages from the primary paging device to the 
secondary paging device when the system speci¬ 
fied level of activity on the primary paging device 
is reached. 

In all, there are some 44 differences between 
these operating systems. The following are the 
major VS1 differences: 

• JES readers and writers replace the old job 
management routines. Although JES doesn’t 
require a dedicated partition, one must be 
available to start and stop its readers and 
writers. 

• Specifiable job classes per partition have 
been increased from 3 to 15. 
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• The interpreter function is no longer a sub¬ 
task of the reader, but rather occurs at 
job initiation time, as a subroutine to the 
initiator. 

• The contents of the job queue have been 
changed. A SWADS data set is now provided 
for each initiator, thus reducing the con¬ 
tention for the job queue. 

• JES provides a spool data set. In addition 
to SYSIN and SYSOUT, ICL messages, WTP 
messages, and system log data sets are in¬ 
cluded in the spool data set. 

• Programs compiled using PL/I F and the 
teleprocessing facilities of this language 
translator cannot be run under VS1 because 
PL/I F uses QTAM. These programs can 
be recompiled using the PL/I checkout 
compiler or the PL/I optimizing compiler, 
both of which use TCAM as their telepro¬ 
cessing access method. 

• Programs previously requiring 64K, 128K, 
192K, and so forth, may require an addi¬ 
tional 64K of virtual partition area to ac¬ 
commodate the system requirements (such 
as protected queue area). 

• MFT supports tape and disc for SMF out¬ 
put. VS1 supports disc only. 

• Programs that modify active CCW strings 
require changes in order to execute in a 
virtual storage system. 

• Commands in the input stream between jobs 
are processed at reader time; those within 
the job, at interpreter time. 

• Users with I/O appendages must code a 
page-fix appendage in their programs to in¬ 
terface with IOS and fix the I/O appendages 
associated with the program. 

• Programs that declare or reference certain 
PSW fields directly, such as the system 
mask, interrupt code, condition code, pro¬ 
gram mask, ILC, and bit 12 of the PSW 
must be changed. 

• Programs using the SSK and ISK instruc¬ 
tions will be affected because the operand 1 
register now contains the 1 ’change and ref¬ 
erence” bits as well as the storage key and 
fetch protect bit. 

• The SSM instruction will have degraded per¬ 
formance due to interrupt processing. 


• Programs executing the LPSW instruction 
must be carefully checked because of the 
changes in the PSW format. 

• No EXCP support is provided for SYSIN/ 
SYSOUT data sets. 


• DSCBS and user labels are not supported 
with SYSIN/SYSOUT data sets. 

• SMF data set compatibility is not supported 
because the format and content of SMF 
records has changed. 

• VS1 does not support: 

— Main Storage Hierarchies (obviated by 
virtual storage concept). 

— QTAM (superseded by TCAM). 

— RJE (superseded by RES). 

— IEBUPDAT (superseded by IEBUPDTE). 

— TESTRAN. 

— GJP. 

— SGJP. 

— IBCRCVRP (superseded by IEHATLAS). 

- HASP. 

— IMAPTFLE (replaced by HMAPTFLE). 

— EMDMDMAP (replaced by HMBLIST). 

— IHGUAP Utility. 

• MFT provides 3 reader procedures with 
the system; VS1 provides two. 

• Output is spooled to DASD by JES and unit 
record UCBS are not created. Any user 
programs that handle conditions such as 
print overflow (channel 12) by checking bits 
in the UCB will not operate properly. 

• VS1 TCAM line groups can contain a maxi¬ 
mum of 32 lines, except for the IBM 2260 
(local attachment) for which there is no 
maximum. 

• RBS, and so forth, have been moved to the 
PQA and are therefore not in the problem 
program area. 
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• A PQA (one per partition) is provided in 
VS1. This does not exist in OS/MFT. 

• Programs referencing storage not obtained 
with GETMAIN or referenced after a 
FREEMAIN may not execute. 

• In VS1, SYSIN blocking is transparent to 
the user. For BSAM interface, records 
are dynamically reblocked to user 
requirements. 

• No DADSM facilities (OBTAIN, SCRATCH, 
RENAME) are supported for the SYSIN/ 
SYSOUT data set. 

• SYSOUT data sets can only be written se¬ 
quentially without repositioning. No support 
is provided for NOTE/POINT, for update, 
or for reading SYSOUT. Once written, SYS¬ 
OUT records cannot be erased or overlaid. 

• In VS1, NOTE/POINT support for SYSIN is 
subject to the following restrictions: 

The user must save 4 bytes of data (TTRL) 
instead of 3 as in MFT. 

POINT to following record (TTR01) is not 
supported. 

Track numbers (TT) do not begin with 0 and 
are not in ascending sequence. 

• No SYSIN support is provided for update or 
for overlaying or adding to the data. 

• SYSIN support for variable length records 
is not compatible. For MFT, block and 
record descriptor fields must be punched 
(in binary) in the input card image. In VS1, 
the entire 80-byte image is treated as data, 
and block and record descriptor fields are 
prefixed to it. Both blocked and unblocked 
formats are supported for SYSIN, but 
spanned records are not. (VS and VBS are 
supported for SYSOUT along with the other 
variable length formats.) 

• ALL SYSIN records processed by QSAM 
contain 1 logical record per original 80- 
byte card image. It is not possible to 
divide cards into multiple logical records 
or to combine multiple cards into a single 
logical record except by using BSAM with 
user deblocking routines. 

• BSAM SVCS BSP and FEOV are not sup¬ 
ported in VS1 and will result in an error 
return if issued. 


• SYNADF can only be issued from within a 
SYNAD exit in VS1. 

• SAM chained scheduling is supported for 
V = R jobs only. 

• TCAM message control programs and 
TCAM message processing programs using 
the ICOPY, TCOPY, QCOPY, and TCHNG 
macro must be reassembled and relinked. 

OS/VS2 and MVT 

OS/VS2 is a functional extension of OS/MVT. 
The enhancements offered by OS/VS2 aren r t as * 
extensive as those associated with DOS/VS and 
OS/VS1, but OS/360 MVT when used properly is 
a fairly competent operating system as it stands. 
Enhancements include: 

• Support of a single regionalized virtual 
storage of up to 16 million bytes divided 
into 64K segments (on external page store) 
and 4K-byte pages. 

• Protection of up to 63 independent jobs. 

• Dynamic job dispatching. 

The processing program support is the same 
as that offered with OS/VS1. OS/VS2 also pro¬ 
vides the same integrated emulator advantages 
of OS/MVT. 

For the most part, programs and data will op¬ 
erate without change under VS2, with a few excep¬ 
tions (for example, those sensitive to PSW for¬ 
mat). MVT features not supported are Testran, 
old remote job entry, Conventional Remote Job 
Entry (replaced by TSO), Graphic Job Processor, 
Satellite Graphic Job-Processor, Storage Hier¬ 
archy Support and Roll-in/Roll-out (both not 
needed with virtual storage), and QTAM (super¬ 
seded by TCAM). Support for System/360 Model 
65 multiprocessing also is unavailable. 

Attached Support Processor (ASP) for real¬ 
time process control and data acquisition applica¬ 
tions is supported by OS/VS2 in both local and 
real main environments. 

The following are the major VS2 differences: 

• In VS2 lists of system parameters may be 
preformatted for use during system 
initialization. 

• Part of MVT NIP has been replaced by a 
new system generation option, DEVSTAT. 
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• Authorized program facility (APF), DEB 
validity checking, and LSQA provide in¬ 
creased system integrity. 

• Chained scheduling is supported only in non- 
pageable storage. 

• SMF data set is not supported on tape. 

Also, SMF records in VS2 contain additional 
information. 

• Priority queuing must be specified for all 
devices containing the page data set. 

• VS2 subpools are allocated in 4K (page) 
blocks versus 2K blocks in MVT. VS2 also 
uses a ’’best fit” algorithm (that is, storage 
closest in size to the request) versus a first 
fit algorithm (that is, storage that is large 
enough to accommodate the request) in 
MVT. 

• No maximum channel program length is 
provided. 

• Storage protection implies both store and 
fetch protection. 

• All modules residing in the SYS1.LPALIB 
data set are brought into the link pack area 
at IPL time. If a BLDL macroinstruction is 
issued for any of the modules, a return code 
indicating ’’not found” is returned since the 
SYS1. LPALIB data set is no longer con¬ 
sidered part of the system after IPL. 

• Any modification (by way of AM ASP ZAP or 
the linkage editor) to modules that were 
made resident in virtual storage at IPL will 
require a subsequent re-IPL to cause the 
modification to become part of the system. 
This would include any module selected at 
system initialization via FIX and MLPA 
options as well as all modules from SYS1. 
LPALIB. If a module contained in SYS1. 
LPALIB is modified at re-IPL, either the 
pageable LPA must be rebuilt or the modi¬ 
fied LPA must be used to cause the modifi¬ 
cation to become part of the system. 

• An OPEN macroinstruction must be issued 
for every data extent block (DEB) created 
in order to support DEB validity checking. 

• VS2 does not support the 6- and 24-hour 
pseudo-clocks, and interruptions from 
location 80; these functions are replaced 
by the time-of-day clock and the clock 
comparator. 


• The LPA directory cannot be modified after 
system initialization. 

• VS2 allows the operator to cancel a job 
waiting for storage or a data set. 

• SVC DUMP has been expanded to allow 
dumping of selected area of virtual storage 
and selective setting of the system to 
nondispatchable. 

• Dynamic device reconfiguration for the sys¬ 
tem residence device and the page data set 
is not supported. 

• Only linkage editor F is distributed with 
VS2. In the JCL, only the aliases IEWL or 
LINKEDIT can be used; other names can be 
used only if the linkage editor is re-linkage 
edited with the other names declared as 
aliases. 

• User-written EDIT exit routines for GTF 
running under MVT must be modified for 
operation in VS2 because of differences in 
the format of trace data for system events. 

• VS2 assembler replaces both assembler E 
and assembler F. If the user has any 
macro instructions that have the same 
names as any new commands or instruc¬ 
tions of the VS2 assembler, the macro 
instructions will be interpreted erroneously 
as the assembler commands or instructions. 

• To ensure that direct access volume serial 
number verification is effective for the vol¬ 
ume containing the page data set, the user 
must ensure that the direct access volume 
verification modules are always part of the 
fixed LPA and that a fixed LPA is specified 
at each IPL. The necessary modules to 
accomplish this are provided in the IBM- 
supplied list IEAFIX00. 

• In MVT, the user can issue a READ CCW 
and rely on the SLI bit to terminate data 
transfer. In VS2, the user must ensure 
that the buffer area assigned within his re¬ 
gion is large enough to contain the full count 
specified in the CCW; if not, the request 
will be terminated. (Note that the assigned 
buffer space must be allocated space within 
the region.) 

• In MVT and VS2, a user data set can be 
shared by tasks in the same family tree 
structure. In VS2, however, the user must 
ensure that all I/O is completed before the 
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issuing task terminates. For a data set 
that is not owned by the terminating task 
(that is, was not opened by the terminating 
task), the terminating task will be abnor¬ 
mally terminated. For tasks with nontele¬ 
processing I/O outstanding, ABEND code 
E06 describes a mechanism to complete the 
I/O. Tasks with outstanding teleprocessing 
1/O must update their programs to ensure 
that the I/O is complete. 

In addition, the following functions are not 
supported by VS2: 

• Conversational Remote Job Entry (this is 
replaced by the time-sharing option). 

• IEBUPDAT utility program (replaced by 
IEBUPDTE utility). 

• IEHIOSUP utility program (obviated by the 
deletion of most modules from the SVC 
library). 

• QTAM (replaced by TCAM). 

• Roll-out/roll-in (obviated by demand 
paging). 

• Scatter load (obviated by demand paging). 

• System environment recording routines 
(provided by recovery management). 

• Automatic SYSIN batching (ASB) reader. 

• Direct system output (DSO) writer. 

• Graphic job processor. 

• Main storage hierarchy support. 

• Multiprocessing. 

• Remote job entry. 

• Satellite graphic job processor (SGJP). 

• TESTRAN. 

VS1 and VS2 Differences 

The major differences between VS1 and VS2 
are small but noteworthy: 

• VS1 Release 1 is an extension of MFT Re¬ 
lease 20.1; VS2 Release 1 is an extension 
of MVT Release 21. 


• VS1 divides storage into pages of 2K bytes 
each; VS2 divides storage into pages of 4K 
bytes each. 

• VS1 allocates external page storage on as 
many as 8 devices; VS2 allocates external 
page storage on as many as 16 devices. 

• VS1 reader procedure specifies PGM = 
IEFVMA; VS2 reader procedure specifies 
PGM = IE FIRC. 

• VS1 uses transient areas; VS2 uses the link 
pack area. 

• VS1 supports the function provided by the 
OUTLIM parameter of the DD statement; 
VS2 does not. 

• VS1 service aid HMDPRDMP formats and 
prints VS1 dumps only; VS2 service aid 
AMDPRDMP formats and prints VS2 dumps. 

• VS1 service aid HMDSADMP reads records 
of 2K bytes each; VS2’s AMDSADMP reads 
records of 4K bytes each. 

• VS1 allows 15 jobs to run concurrently; 

VS2 protects up to 63. 

• VS1 supports job processing by way of JES; 
VS2 still employs the MVT job management 
routines (JES support is scheduled for VS2 
Release 2). 

• VS1 does not support time sharing; VS2 
does. 

VIRTUAL STORAGE CONCEPT 

The most talked about feature incorporated 
into the operating systems that were introduced 
to support new versions and new models of the 
System/370 is virtual storage. 

Virtual storage amounts to nothing more than 
using high-speed discs or drums to provide in¬ 
expensive expansions to the main processor. 
Please don T t make the mistake of thinking that 
virtual storage means "virtually the same as 
real memory." Virtual means: in essence or 
effect, but not in fact . Virtual storage, then, is 
an adjunct to real memory, and a slow one at 
that. 

The use of virtual storage — according to 
marketers — allows programs normally too large 
to fit into available memory partitions or regions 
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to "get a shot" at the CPU. Also, since the pro¬ 
grammer need no longer concern himself with the 
program size, he can concentrate on the prob¬ 
lem — that’s what the marketers say. There’s a 
lot about virtual storage they don’t say; read 
about it under Description and Evaluation . 

In case you’re not familiar with virtual mem¬ 
ory (or virtual storage as IBM calls it) terminol¬ 
ogy, storage is classified as being real or vir¬ 
tual. Real storage is the computer’s internal, 
physical storage; virtual storage is the applica¬ 
tion of a high-speed, direct-access device (disc 
or drum) as if it were main processor storage. 
Programs can run in a purely real mode, purely 
virtual mode, or a combination of both. 

To understand the interaction of virtual and 
real storage some reorientation in your concept 
of main storage is necessary. First of all, main 
storage is called real, while the back-up high¬ 
speed storage is called virtual. The sum of the 
real storage plus that allocated for virtual use is 
called the virtual storage system. 

For example, a virtual system can be 200K 
bytes long with 75K being real storage. That part 
of the virtual storage which can be directly 
equated to real storage is called the real address 
area. Here it is 0 to 75K. 

That part beyond the end of the real address 
area, up to the limit of the virtual storage de¬ 
clared at system generation, is the virtual ad¬ 
dress area. In this case it’s 76K to 200K. A 
more detailed treatment of how storage is allo¬ 
cated and controlled is found under Main Storage 
Allocation . 

Storage addresses up to the logical limit of 
the system’s addressing structure (16,777,216 
bytes in System/370) can then be directly used by 
programs independently of the actual size of sys¬ 
tem main storage. In order to do this, the pro¬ 
cessor must maintain and use an address trans¬ 
lation table that is capable of automatically map¬ 
ping addresses from backing virtual memory into 
main store. This is called dynamic address 
transition. (See Program Loading. ) 

Operating systems for virtual memory assume 
additional responsibilities, the most important of 
which is management of the real memory re¬ 
source. This is called mapping, the procedure of 
maintaining a one-to-one correspondence list of 
virtual memory addresses on backing store ver¬ 
sus real main storage locations. 

Virtual memory can be paged or segmented. 
IBM uses the paging method, which breaks the 


virtual store into multiple fixed and equal-size 
blocks (pages), which are then brought into real 
memory as needed. Real memory assumes the 
role of a page frame. With IBM, the page frame 
and page size is 2K bytes for VS1 and 4K bytes 
for VS2. 

The concept of a partition or region, as had 
existed under earlier IBM operating systems, now 
applies to both real and virtual memory space. In 
a partition, pages belonging to a program are con¬ 
tiguous. If only virtual partitions are used, mem¬ 
ory becomes available to all jobs and page loca¬ 
tions are random; the new operating system pro¬ 
vides linkage. 

Paged memory does allow extremely large 
programs to run. For all practical purposes, in 
fact, partitions in virtual store can be as large as 
needed. 

Virtual storage is possible under System/370 
architecture due to dynamic address translation, 
extended control mode operation, and channel in¬ 
direct addressing. 

Extended Control (EC) mode provides an ex¬ 
tended format for the processor’s program status 
word (PSW), thereby gaining control over several 
System/370 functions unavailable in the previously 
used basic control mode. 

Channel Indirect Data Addressing allows a 
single channel control word (CCW) to span several 
pages in noncontinuous real storage during 1/O 
data transmissions. For each CCW that potenti¬ 
ally spans a page boundary, the channel control 
program automatically generates an indirect ad¬ 
dress list. This facility is different from data 
chaining, which requires a unique CCW for each 
data address noncontiguity and also must be con¬ 
sciously programmed. 

The chief drawback of paged virtual memory is 
that a system could require page swaps between 
memory and virtual store at such a rate that the 
system is overwhelmingly preoccupied with paging 
to the exclusion of useful work. This activity is 
called "thrashing." IBM attempts to prevent 
thrashing in 3 ways: by selecting a page size ap¬ 
propriate to the operating system; by using a 
priority scheduling algorithm that allows paging 
of only the highest-priority jobs in the event that 
thrashing begins; and by allowing the user to se¬ 
lect the most advantageous combinations of CPU 
power, real store size, and device type used for 
virtual store. 

When a page must be called in and all real 
memory page frames are filled, a "page fault" is 
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Figure 1. OS/VS 1 and 2 Program Loading 


encountered, and the new page called in replaces 
the least recently used page in real memory. IBM 
further reduces interference due to paging by pro¬ 
viding 2 additional bits associated with each real 
memory page frame. One is a use bit and one a 
change bit. If the page to be replaced has not been 
changed during its use, it is not written out to ex¬ 
ternal page store but is simply overwritten in real 
memory by the new page brought in. 

It should be pointed out that theoretically any 
system could implement virtual memory in soft¬ 
ware. All that needs to be done is to apply traps 
for addresses and create a reference table and 
mapping program. When important functional 
aspects of such a system are hardware imple¬ 
mented, a manufacturer can more validly claim 
to have developed a virtual memory system. 

Users shouldn’t allow themselves to be ’’wowed” 
by buzzwords like virtual memory. They should 
also remember that the direct access backing 
store for virtual store implementation is 3 to 5 
orders of magnitude slower than a computer’s 
main store. 

Another point should be made clear to users 
of virtual memory systems, namely, the execu¬ 
tion time for a specified job in a virtual system 
is likely to be longer than in a nonvirtual system. 
The advantage presented by the virtual system is 
in multiprogramming efficiency for total system 
throughput. The problem that IBM is addressing 
is that the jobs which could have run quite nicely 
on the nonvirtual system often could not, in real 
life, get on the system to run. 

PROGRAM CONSTRUCTION 

No radically new programming techniques are 
required for VS1 and 2, except maybe that the 
programmer should lay out his job so that the 
more frequently called routines will ultimately 


appear on contiguous pages. That should lighten 
the overhead load associated with a paged system. 
Beyond that, program construction and linking 
are the same as under OS/M FT and MVT. 

PROGRAM LOADING 

A program is loaded for execution by trans¬ 
ferring pages from a program library to the ap¬ 
propriate job queue and then to the designated 
virtual storage partition or region. If sufficient 
page frames are not available, pages are paged 
out to the Page Data Set until the entire program 
is loaded. The capacity of the Page Data Set is 
equivalent to the size of the system’s virtual = 
real address area. (See Main Storage Alloca¬ 
tion . ) The loading procedure is shown in 
Figure 1. 

During execution, nonresident referenced 
pages are retrieved from the Page Data Set. If 
the contents of a page in storage have been altered 
or a duplicate copy of a replaced page does not 
exist, the page is transferred to the Page Data 
Set before the new one is brought in. When the 
page is to be returned to its partition or region, 
it always goes to the page frame where it origi¬ 
nally resided. 

Pages are located and transferred into real 
storage by way of a Dynamic Address Transla¬ 
tion (DAT) procedure. DAT provides an automatic 
2-level address translation and mapping process 
that utilizes page and segment tables to yield an 
effective storage address span of 16,777,216bytes 
(16 megabytes). Segments on external page store 
of 64K or 1 million bytes are broken into pages 
of 2K in the case of DOS/VS and VS1 or 4K bytes 
in the case of OS/VS2 (K= 1,024 bytes). With ad¬ 
dress translation, all 24 bits of an address are 
usable, thus providing the 16,777,216 bytes of 
addressable storage. This address space is 
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divided into 256 segments of 64K bytes each; each 
segment in turn is subdivided into 32 pages of 2K 
bytes for VS1 and 16 pages of 2K bytes for VS2. 

Page addresses are treated as logical address¬ 
es, and the translation develops the real address. 
The address translation part of the process is 
hardware implemented; page mapping is under 
supervision of the operating system. The trans¬ 
lation and mapping process is transparent to the 
user, who simply operates with the usual logical 
address structure. 

An associative array, which is an 8-entry 
buffer that holds the most recently used main 
storage addresses, is used for this special pur¬ 
pose instead of main memory to increase the 
speed of virtual memory access and to lessen 
CPU interference caused by paging. 

STORAGE ALLOCATION 

Storage is allocated to handle both real and 
virtual addresses. Real storage is that portion 
from which the CPU can directly obtain instruc¬ 
tions and data and to which it can directly return 
results. Virtual storage is address space that 
appears to the user as real storage. From this 
address space, instructions and data are mapped 
into real storage locations. If virtual only parti¬ 
tions are used, partitions are assigned from 
available virtual storage; the system assigns real 
storage only as it is actually needed for program 
use. 

Real Storage 

Real storage is allocated pretty much the same 
way as was done for MFT and MVT. It is used 
for supervisor routines, spooling program (JES), 
teleprocessing, real address areas, and execu¬ 
tion of programs from the virtual address area. 

Portions of the real address area are allocated 
to the partitions or regions defined during system 
generation. Fifteen partitions can be generated 
in VS1, ranging from foreground 1-15; up to 63 
region can be protected with VS2. All partitions 
that will ultimately be used during the run must 
be SYSGENed at the same time. Processing pri¬ 
orities range from foreground-1 highest through 
to foreground-15 lowest. Partition sizes and pri¬ 
orities may be changed by the operator to meet 
processing needs. 

Virtual address processing is an alternative to 
running a program in real mode. Instructions, 
however, must be physically resident in real 
storage to be executed; the operating system as¬ 
sumes the responsibility for placing the code from 


the virtual address area into real storage for 
execution. 

Real storage is divided with fixed and paged 
sections. The fixed section, located in the lower 
portion of real storage, contains the resident 
supervisor and any jobs executing in a virtual = 
real (V = R) mode. The size of the fixed area de¬ 
pends on the amount of storage the user requires 
to execute his programs in V = R space (which is 
fixed only while the V = R program is executing), 
the resident supervisor requirements, the Sys¬ 
tem Queue Area (SQA), and the Recovery Man¬ 
agement Support (RMS) area. With VS1 and 2, 
the fixed area is that part of real storage into 
which the nucleus is loaded at IPL. 

The V = R mode provides for the types of pro¬ 
grams that cannot run in a paged environment; 
for example, programs that modify the channel 
program while it is active, time dependent pro¬ 
grams with user written I/O appendages that do 
not adhere to system programming rules, and 
programs that require all their pages to be in 
processor storage while they are executing. 

The paged section resides in the upper portion 
of real storage and contains portions of the prob¬ 
lem programs currently executing and the page- 
able portions of the Supervisor as they are 
needed. It also contains, as needed, 2 transient 
areas: the SVC transient area and the I/O tran¬ 
sient area. JES is also located in this section. 

Virtual Storage 

In a single task environment, virtual storage 
is divided into a nonpageable area and a pageable 
area. The nonpageable area is located in the 
lower portion of virtual storage and contains the 
resident portion of the control program, and con¬ 
trol blocks and tables used by the system and the 
system queue. The size of this area depends on 
the number of partitions or regions established, 
and the control program options selected at sys¬ 
tem generation. 

All partitions to be used are defined atSYSGEN 
within the pageable area. The number of parti¬ 
tions may be varied within the number specified 
at system generation, and the sizes and job 
classes of partitions can be redefined at system 
initialization or during operation. Each partition 
or region can be occupied by a processing pro¬ 
gram or by control program routines that prepare 
job steps for execution (job management routines) 
or that handle data for a processing program (ac¬ 
cess method routines). As many as 15 problem 
programs in VS1 and 63 in VS2 can be processing 
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concurrently. Each program is located in its own 
partition or region of virtual or real storage, with 
input readers and output writers, under control of 
JES in VS1. The VS1 system provides for task 
switching among the tasks in the partitions, and 
between those tasks and the communications task 
and master scheduler task in the system area. 

In the pageable area, job management routines, 
processing programs, and routines brought into 
storage by way of a LINK, ATTACH, or XCTL 
macro instruction are loaded at the lowest avail¬ 
able address. The highest portion of the partition 
is occupied by the user parameter area and user 
save area. The next portion of the partition is 
occupied by the task I/O table (TIOT), which is 
built by a job management routine (I/O device al¬ 
location routine). This table is used by data man¬ 
agement routines and contains information about 
DD statements. 

Each partition can be used for a problem pro¬ 
gram as well as for system tasks. When the con¬ 
trol program requires virtual storage to build 
control blocks or work areas, it obtains this 
space from the partition of the processing pro¬ 
gram that requested the space. Access method 
routines and routines brought into storage by way 
of a LOAD macro instruction are placed in the 
highest available locations below the task I/O 
table. Working storage and data areas are as¬ 
signed from the highest available storage in a 
partition. 

The high portion of the pageable area is occu¬ 
pied by the pageable supervisor routines, dump 
area, pageable system queue area, and JES 
routines. It also contains 2 transient areas into 
which certain nonresident routines are loaded 
when needed: the SVC transient area (2,048 bytes) 
and the I/O supervisor transient area (1,024 
bytes). These areas are used by nonresident SVC 
routines and nonresident I/O err or-handling 
routines, respectively. 

Each transient area contains only 1 routine at 
a time. When a nonresident SVC or error-han¬ 
dling routine is required, it is read into the ap¬ 
propriate transient area. The transient area 
routines operate with a protection key of zero, as 
do other routines in this area. 

Storage Management 

Storage is assigned according to partition pri¬ 
ority and storage requirements of each program 
at different stages of its execution. The system 
can also temporarily suppress one or more pro¬ 
grams when there is not enough real storage to 
support all programs running in virtual mode at 


a reasonable level of performance. The more 
real storage available for this storage manage¬ 
ment activity, the higher the percentage of the 
installation’s programs running in virtual mode. 

When the limitations of real storage prevent 
all programs running in virtual mode from being 
simultaneously present in real storage, the oper¬ 
ating system exchanges pages between the Page 
Data Set and real storage as they are required for 
execution. 

Real storage, as was previously mentioned, 
consists of a nonpageable section and a pageable 
section. The resident supervisor, including the 
nucleus and the system queue area, occupies the 
nonpageable area. The pageable area is occupied 
by pages of programs (users’ and systems’) which 
are brought into it for execution and are then re¬ 
turned to auxiliary storage. 

Two types of programs exist that cannot run in 
a paged environment: EXCP programs that mod¬ 
ify the channel program while it is active, such 
as OLTEP; and highly time-dependent programs. 
These programs, however, can run if the user 
specifies how much real storage he needs in a 
nonpaged environment. Storage will be allocated 
at job execution time as needed. Virtual ad¬ 
dresses will still be processed by the dynamic 
address translation feature, but page tables will 
be built so that the translated addresses are the 
same as the untranslated address. 

The V = R execution facility allows a user to 
have real storage available for any of his pro¬ 
grams that will not run in the normally paged en¬ 
vironment. Real storage will be allocated at job 
execution time with real storage addresses equiv¬ 
alent to virtual storage addresses on a byte basis, 
for the equivalent amount of virtual storage he 
has defined for the job involved. Multiple V = R 
jobs can execute concurrently if enough real stor¬ 
age is available in the system to accommodate 
the jobs. 

The size of the V = R area must be specified by 
the user at system initialization time. System de¬ 
fault for the V = R area is 512K bytes or the en¬ 
tire real storage size of the machine , whichever 
is less. 


When a request for V = R area is received, the 
system scans the V = R area for the requested 
amount of contiguous real storage. If storage is 
available, the request can be honored immedi¬ 
ately. If a conditionally suitable area (containing 
no long-term fixed pages) is located, it is as¬ 
sumed to be conditionally available to honor the 
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V = R request. Pages within this area are tagged 
for interception and subsequent use for V = R ex¬ 
ecution. When all pages in the area are no longer 
required for currently executing programs and 
have been paged out or relocated in real storage, 
the area becomes available and the V = R request 
can then be honored. 

PARTITIONS AND REGIONS 

The number and size of the system partitions 
are declared at SYSGEN. Up to 15 problem pro¬ 
gram partitions and 37 system task partitions can 
be generated for VS1, and 63 problem program 
regions and 14 system tasks can be declared for 
VS2.* Minimum partition size is 64K bytes, ex¬ 
pandable in 64K-byte increments. Region sizes 
are variable. Partitions and regions are used the 
same way as with MFT and MVT, with one ex¬ 
ception: system task partitions are not required 
to run readers and writers. These (with the ex¬ 
ception of the direct system output writers) oper¬ 
ate from the pageable supervisor area in virtual 
storage. 

The number, size, and job classes assigned 
to partitions can be redefined any time after IPL. 
Dormant adjacent partitions can be combined to 
accommodate jobs with large storage require¬ 
ments; these partitions may be reestablished sub¬ 
sequently (within system generation limits) when 
the need for a large partition has passed. Job 
classes assigned to a partition may be changed 
also to accommodate changes in the work load for 
one or more job classes. Partition redefinitions 
must be made in increments of 64K bytes. 

If a partition is operating and the need arises to 
deactivate it, the processing job must be canceled 
or stopped. Any number of adjacent partitions 
may be combined. Partitions that were combined 
can be reestablished or recovered when the com¬ 
bined space is no longer needed. 

VS1 problem program partitions also have 
storage protection and fetch protection features 
which allow a unique protection key to be available 
for each partition. A list is kept of each available 
key for subsequent reassignment to combined or 
recovered partitions. When partitions are com¬ 
bined or recovered, the first available protection 
key on the list is assigned to them. 

Partition Deactivation/Reactivation 

With this feature, the operator can declare a 
partition eligible or ineligible for deactivation if 


*System tasks run in nonpageable dynamic 
storage. 


the need should arise to appropriate the parti¬ 
tion's resources, or he can reactivate any de¬ 
activated partition. The declaration is usually 
done at IPL time but can be done later by way of 
a DEFINE command. 

Although this feature is extremely useful, it 
can present some serious problems when not used 
properly. For example, if the partition used by a 
user-written teleprocessing application is de¬ 
activated, the entire teleprocessing network could 
fail. 

IBM cautions that whenever the operator rein¬ 
states a currently deactivated job, he should 
mark other active tasks eligible for deactivation. 

If this is not done, the amount of real storage 
available to the reactivated and currently running 
jobs can be decreased to the point where the ac¬ 
tive partitions could cause excessive paging and 
eventually thrashing will result. 

JOB STREAMS 

Job streams are usually built for execution in 
a specific partition. Each program executes 
either in real mode or in virtual mode, and each 
partition can be redefined by the operator to meet 
existing processing needs. 

Each partition usually has a processing priority 
associated with it. Up to 15 job classes can be 
specified for a partition, as opposed to 3 for par¬ 
titions with MFT. 

Incoming jobs are taken directly from the in¬ 
put stream and enqueued directly in the job 
queues, corresponding to a job class parameter 
specified by a job control statement. The job 
statement identifies the job and contains user- 
specified priority data (if applicable) plus some 
accounting information. 

If priority schedulers are used, job class in¬ 
formation can also be assigned to jobs. The class 
assignment determines where the job is placed in 
its respective queue; the priority parameter de¬ 
termines the job’s initiative priority within its 
job class. Jobs of equal priority are enqueued on 
a FIFO basis. 

All jobs compete for resources concurrent^. 
Each job is selected for execution from an input 
queue according to its priority within a class. 

Each step of each job is executed sequentially. 

Jobs are scheduled according to their job class 
identifier, their priority within the job class 
queue, and the availability of a partition corre¬ 
sponding to the appropriate job class. Scheduling 
control is provided by the job entry subsystem 
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(JES). JES analyzes the input stream, allocates 
I/O devices, selects jobs for execution, reads 
and writes job data, and provides the communica¬ 
tion link between the operator and system. 

TASKING 

VS1 and 2 also permit multitasking. The num¬ 
ber of tasks that can execute in each partition de¬ 
pends on whether the programmer uses the 
ATTACH facility. If this facility is not used, only 
1 task will execute in each partition. 

When the ATTACH facility is used, each task 
can attach any number of subtasks up to a maxi¬ 
mum of between 196 and 249. Each subtask ex¬ 
ecutes in the same partition as the attaching task. 

The reason for the variation in the number of 
attachable subtasks involves the use of TCBs 
(task control blocks). Each attached subtask re¬ 
quires a TCB. Up to 255 TCBs are available in 
the system. Of these, the system needs at least 
5. Each active partition (or task active in a 
partition) also requires 1 TCB. In a single par¬ 
tition configuration with minimum system options, 
6 TCBs are not available for subtasking. This 
reduces the number available for subtasks to 249. 
As more system options and/or partitions are 
added, additional TCBs are required, up to a 
maximum of 59. This produces the lower limit 
of 196 available for subtasking. 

JOB INITIATION AND DISPATCHING 

Please note that a job’s priority applies only 
to the initiation priority, not to the dispatching 
priority. The dispatching priority determines 
which job should be given control of the CPU. In 
VS1, dispatching priority is derived from the rel¬ 
ative position of the partitions: PO has the highest 
priority, P51 lowest. It varies with VS2. 

A task’s dispatching priority is determined by 
the relative position of the task control block 
(TCB) on the dispatching queue. (The dispatching 
queue is the chain of TCBs indicated by the 
TCBTCB fields.) 

If subtasking is not used, all TCBs are es¬ 
tablished in the nucleus at system generation. 
These are ordered to provide a dispatching pri¬ 
ority starting with resident system task TCBs, 
through the job step task TCB of the highest pri¬ 
ority partition (PO), to the successively lower 
priority partitions ’ TCBs (P1-P51). Control of 
the CPU is given to the program represented by 
the highest-priority ready TCB. 

If subtasking is used, TCBs established at 
system generation in the nucleus represent the 


resident system tasks and the job step task of 
each partition. However, each job step task can 
attach subtasks, each of which will have a TCB 
located in the partition’s protected queue area. 

Dispatching 

The dispatching priority is initially the same 
as the partition’s priority. The dispatching pri¬ 
ority differs when a job step task issues a CHAP 
(change priority) macro instruction to change its 
dispatching priority. If dispatching priorities are 
not changed, each partition’s or region’s job step 
task is dispatched before its subtasks, which are 
then dispatched in the order in which they were 
attached. When all of a job step’s subtasks have 
been dispatched, the job step task of the next 
lower partition or region can be dispatched. 

If the time-slicing feature was specified at 
system generation, the effective dispatching pri¬ 
ority of a group of time-sliced partitions can be 
altered. Time-slicing allows the user to establish 
one group of consecutive partitions in which the 
task in each is assigned a uniform interval of 
time to retain control of the CPU. In VS2, time 
slices are assigned by task associated with a 
group. When the allotted time has elapsed, the 
next lower-priority ready task gains control of 
the CPU for its allotted time. This process con¬ 
tinues until either all tasks are waiting and com¬ 
pleted, or until a task of higher priority becomes 
ready. The size of the time slice for each task 
may be varied from 20 to 9,999 milliseconds. 

VS1 and VS2 also provide a feature called 
dynamic dispatching, a safeguard intended to pre¬ 
vent CPU-bound tasks from monopolizing the ma¬ 
chine while I/O resources are idle and I/O domi¬ 
nant tasks are dispatchable. 

Dynamic dispatching alters the dispatching 
priorities’ selected tasks as they are being ex¬ 
ecuted. It calculates the dispatching priorities 
so that tasks can use the system resources more 
efficiently. It not only alters the handling of each 
task as its characteristics change, it also evalu¬ 
ates itself and alters itself based on its effective¬ 
ness in handling the tasks under its control. 

Initiator 

An initiator can be started in each problem 
program partition that is defined at SYSGEN. 

When each initiator is started, job management 
allocates an area on DASD called SWADS (sched¬ 
uler work area data set). Each SWADS holds the 
tables for the problem program currently handled 
by that particular initiator. Thus, it is a sequen¬ 
tial data set that is reusable; that is, the tables 
for a new job overlay those from the previous job. 
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The SWADS is deallocated when the stop command 
for that initiator is processed. 

The initiator selects a job from the input work 
queues established by the system input reader and 
schedules it for execution. Initiators obtain jobs 
for partitions based on the job classes assigned 
to the partitions and the priority of the jobs within 
their job classes. The initiator interfaces to al¬ 
location procedures for device allocation. The 
job is then scheduled for execution. An initiator 
is given control after a job has been terminated. 

When the job terminates, the initiator then 
schedules the next available job into its partition 
and passes control to the first step of that job. 
When system output writers are used, output data 
sets are placed on direct access storage devices 
while the job is being processed. The output data 
sets are enqueued by output class and subsequent¬ 
ly retrieved by system output writers. 

Job Termination 

The termination program determines first 
whether step termination or job termination is to 
be performed. Step termination includes dis¬ 
posing of data sets, deallocating I/O devices, 
processing condition codes, and executing an ac¬ 
counting routine. If the job contains additional 
steps, control is returned to the initiator to 
schedule the next job step. Job termination is 
performed after the last step of a job has been 
terminated. An accounting routine is executed; 
data set disposition and 1/O deallocation, which 
could not be done at step termination, are 
completed. 

If the job uses direct system output writers, 
its output is written directly to an output device 
or devices; no intermediate device has to be used 
and no output work is enqueued. 

LANGUAGE SUPPORT 

VS1 and 2 support the same high-level lan¬ 
guages as MFT and MVT. Programs for those 
systems should run with no modification. 

IBM, however, has provided a new system 
assembler that allows implementation of pro¬ 
grams using the System/370 instruction set. The 
assembler gives the user access to hardware and 
operating system functions and permits the user 
to generate and maintain the virtual storage. 
Among the features supported by this assembler 
are: 

• Macro instructions — The macro capability 
is a programming tool providing interfaces 


to the VS1 Input/Output Supervisor by 
means of data management macros, access 
to the complete OS/VS1 capabilities through 
the use of Supervisor macros, and the abil¬ 
ity to include programmer defined macros 
in Assembler programs for special 
applications. 

• Conditional Assembly Statements — These 
are used to alter the sequence in which 
statements are processed, or to specify 
selective assembly of instructions. The 
conditional assembly mechanism is a key 
element in the macro feature. 

• Private Libraries — A private library may 
contain Assembler language statements. 
These can be macro definitions or code that 
is to be inserted into the program by the 
COPY statement. 

• Dynamic Work Areas — The Assembler 
provides a mechanism for establishing 
addressability to independently allocated 
storage areas. 

• System Requirements — The system as¬ 
sembler for VS1 and 2 uses the System/370 
standard instruction set. This Assembler 
runs efficiently in 128K of virtual storage 
and requires a minimum of 64K of virtual 
storage. In addition to the standard re¬ 
quirements, the system Assembler re¬ 
quires space in auxiliary storage for the 
following data sets: system input and 3 
intermediate data sets for work storage. 

Depending on program requirements, additional 
data sets may be needed for Macro Definition li¬ 
brary, print output, object module output, and 
punch output. 

The system Assembler contains the following 
enhancements to OS Assembler F: 

• SETC values and character relation terms 
can be up to 255 characters in length. (The 
old limit was 8 characters.) 

• Fewer restrictions and extended functions 
for conditional assembly language. 

• Three new system variable symbols 
(& SYSPARM, & SYSTIME, and 

& SYS DATE). 

• Extended mnemonics for RR-type branch 
instructions. 

• Improved diagnostics and debugging 
facilities. 
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Programs compiled on the PL/IF compiler 
that use teleprocessing facilities of this language 
translator will not run under VS1 because PL/IF 
uses QTAM. These programs can be recompiled 
on the PL/IF optimizer compiler which uses 
TCAM. 

EMULATORS 

VS1 and 2 allow the user to emulate the 1401, 
1440, 1460, 1410/7010, 707X, 708X, 709X, and 
DOS with no modifications. The emulator and the 
System/370 supporting it are shown in Table 1. 

COMPATIBILITY 

Most programs written for MFT and MVT will 
run under VS1 and VS2, respectively. The ex¬ 
ceptions are programs that: are time dependent; 
are written to deliberately cause program ex¬ 
ceptions; use machine-dependent data; use the 
program status word (PSW) bit 12 (the ASCII bit); 
and use low-address storage reserved for spe¬ 
cial purposes (PSW). Also, programs that: de¬ 
pend on devices or facilities not supported or 
available in System/370 or VS1 and 2; require 
model-dependent System/360 functions; attempt to 
read or write SYSIN or SYSOUT data by other than 
the SAM access method (that is, EXCP will not 
work on these data sets); depend on a valid UCB 
pointer in the TIOT for SYSIN/SYSOUT data sets; 
include TCAM object decks that will not run 
TCAM message control programs and TCAM 
message processing programs using the ICOPY, 
TCOPY, QCOPY, and TCHNG macro instructions 
(these must be reassembled and linkage edited). 
TCAM message processing programs not using 
any of these macro instructions need only to be 
re-linkage edited. 

CONFIGURATION REQUIREMENTS 

OS/VS1 operates on the Models 135 through 168 
(including MP versions). The systems will run on 
as little as 128K bytes and on as much as 1 million 
bytes. A system with processor storage of 160K 
bytes (real) is sufficient for all VS1 standard fea¬ 
tures, but the use of optional SCP features will 
probably require additional real storage. In gen¬ 
eral, the function, advantages, and performance 
depend upon the amount of real storage available; 
therefore most users will find 240K bytes or 
larger to be more efficient for their VS1 systems. 

Peripherals required include: 1 card reader/ 
punch, 1 magnetic tape unit, 2 Model 3330 Disk 
subsystems or an intermix of 3330s and 3340s, 
and 1 high-speed printer. 

OS/VS2 operates on Models 145 through the 168 
(including MP versions). Main storage require- 
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Emulator Mode 

Emulation Model 

135 

145 
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16511/168 

1401/1440/1460 

x + 

X 

X 


1410/7010 

x + 

X 

X 


708X, 709X 




X 

70 7X 



X 


DOS 

x + 

X 

X 


+ VS1 only 


ments are: 385K bytes for batch only processing; 
512K bytes for concurrent batch and time sharing; 
and 1,024K bytes if all options are used. 

The minimum peripherals required are: 1 
multiplexor channel; 1 selector or block multi¬ 
plexor channel; 3 IBM 3330s or 4 IBM 2314 or 
2319 Disks; 1 card reader/punch; 1 line printer; 
and 1 system console. If the 3330s are used for 
system generation, 4 such devices are necessary. 
A 9-track magnetic tape is required to restore 
VS2 from magnetic tape to disc for system gen¬ 
eration and maintenance. 

FUNCTIONAL CHARACTERISTICS 

Job Types 

Batch and data communications. 

Job Scheduling 

Job class or job class/numeric; equal priority 
jobs serviced FIFO (first in, first out) intraqueue; 
queues serviced round robin by priority. 

Resource Allocation 

Main Storage: statically a dynamically as¬ 
signed, fixed size virtual partition. 

CPU Time: variable length time slice accord¬ 
ing to job class. 

I/O Devices: statically assigned. 

Information Files: statically or dynamically 
assigned; shareable and nonshareable programs 
and subroutines permitted. 
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Program Structure and Loading 

Simple, overlay, and dynamic divided by the 
system into 2K-byte (VS1) and 4K-byte (VS2) 
pages; relocatable programs (overlay and 
dynamic). 

I/O Control 

Device Types: disc, magnetic tape, drums, 
data cells, typewriter, unit record devices, 
graphics. 

Buffer Allocation: simple, exchange, chained 
segment, and dynamic. 

Remote Terminal Support: remote batch pro¬ 
cessing; standard terminal speed and format. 
Supports to BTAM, QTAM, VTAM, and CRJE. 

Recovery Processing 

Checkpoint all jobs; restart for beginning of 
job or from checkpoint; tapes automatically 
repositioned. 

Diagnostic Error Processing 

Hardware and software errors recognized; 
hardware errors result in error message (stan¬ 
dard), malfunction indication (optional); or termi¬ 
nation of affected task only (optional); minor er¬ 
rors retried before termination. Program error 
handling routines must be user supplied. 

Processing Support 

Timing Services: interval and real-time. 

Testing and Debugging: snapshot and post¬ 
mortem dumps; routines for testing and debugging 
assembly language programs; routines for testing 
I/O devices, control units, and channels. 

Logging and Accounting 

Standard accounting data and hardware error 
statistics kept; no job accounting routines 
provided. 

File Management 

Indexed libraries of macro code, source code, 
relocatable code, executable code; cataloging is 
dynamic. User and system labels identify files. 

File Structure 

Sequential, indexed sequential, virtual storage 
partitioned, and direct; hierarchical structures 
permitted. 


File Storage Allocation 

Auxiliary storage size and density defined by 
user; storage assigned dynamically. 

File Location 

File name and/or user assigned password 
(down to field level) using master catalog; hier¬ 
archical structures permitted. 

File Access Methods 

Virtual Sequential, Basic Sequential, Basic 
Direct, and Basic Partitioned all standard; 

Basic and Queued Indexed Sequential, and Tele¬ 
processing optional. 

Job Control Language 

Parameter oriented; consists of the following 
5 classes: 

• Job statement — marks the beginning of 
and identifies a job. 

• EXEC statement — indicates the beginning 
of a job step (task) and identifies the pro¬ 
gram or catalog procedure to be executed. 

• Data definition (DD) statement — describes 
a data set and requests allocation of I/O 
resources. This statement also binds the 
internal name of a data set (as used in the 
program), or DDNAME, to an external 
name (the physical file name), or DSNAME. 

• Command statement — used to enter com¬ 
mands through the input stream to activate 
or deactivate system I/O units, request 
displays, or perform other operator func¬ 
tions. Commands currently available in 
the PCP version are: DISPLAY, MOUNT, 
SET, START, STOP, UNLOAD, and VARY. 

• Delimiter statement — terminates various 
aspects of the input stream. 

Sorting and Merging 

The sort/merge programs are part of the op¬ 
erating system and operate under its control. 

Like the operating system itself, the sort/merge 
programs can be tailored to the needs of the in¬ 
stallation at SYSGEN time. 

The sort/merge programs sequence the logical 
records of a data set according to the contents of 
a control word. A control word is user defined 
and can contain 256 bytes of information and up to 
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64 control fields. The programs sort a data set 
of an unknown order into a predesignated order 
and merge up to 16 previously sorted data sets 
into a single sorted data set. 

The programs operate with any level of the op¬ 
erating system and require 15,500 bytes of main 
storage. Of this, 12K bytes are needed for the 
sort/merge programs themselves, while the re¬ 
maining 3,500 bytes are used for system func¬ 
tions. One selector or one multiplexor channel 
is needed, as well as one disc. 

FEATURES AND EVALUATION 

Overall, the features offered by VS1 and 2 
make these operating systems distinctly better 
than their nonvirtual counterparts. Virtual stor¬ 
age does indeed let programs normally too large 
to be scheduled to at least get a shot at the CPU, 
but you pay for this capability with degraded per¬ 
formance. It’s a trade-off, and only you can de¬ 
termine if the benefits outweigh the drawbacks. 

The following paragraphs highlight and evalu¬ 
ate the more outstanding features of VS1 and 2. 

Virtual Storage 

The virtual storage feature supports up to 16 
million bytes, divided into addressable 2K- or 
4K-byte pages. Likewise, the main storage parti¬ 
tion is divided into 2K- or 4K-byte regions (or 
frames, as IBM calls them) to receive these 
pages when entered. 

Reasons for employing paging were not too 
widely known when IBM announced VS, and neither 
were (or are) the real and potential drawbacks. 

The greatest benefits mentioned by the vendor 
are that it relieves the programmer from con¬ 
sidering segmentation and to some extent core re¬ 
strictions when laying out his program; and vir¬ 
tual memory also allows programs normally too 
large to fit to get "a shot at the CPU.” Both 
statements are true. 

The programmer certainly can be a little lax 
in segmenting his program since he no longer has 
a space problem. If he does however, he could 
easily cause considerable throughput degradation. 
You see, when you’re dealing with segmented or 
paged programs the code you need during execu¬ 
tion may not be core resident when called. There¬ 
fore, the system must stop processing the pro¬ 
gram, go out to auxiliary storage and find the de¬ 
sired code, and transfer it to main memory. If 
the processor is preoccupied with this searching 
for codes, it enters a condition called ’’thrashing” 
and no productive work is being done. 


A solid solution to this problem is to have all 
code resident in main storage. But that defeats 
the purpose of virtual storage, doesn’t it? An¬ 
other would be to determine which code is the 
most frequently called, place it on adjacent pages, 
increase the page size, and keep it continuously 
main storage resident. This determining of the 
frequently called code is termed working set 
analysis and is no easy task. 

Simply stated, a working set is the estimated 
number of pages which must be available in cen¬ 
tral storage to allow the job to run. Less pages 
wastes space; the need for too many to fit avail¬ 
able space results in thrashing. The working set 
can be determined by the machine or specified by 
the user. If the user specifies it, a technique 
called ’’lookahead” is employed. Here, the user 
specifies his working set and requires the ma¬ 
chine to have available all the space required to 
load all pages at once. Since the machine is 
handling many jobs simultaneously, it must com¬ 
pare the core requirement with that available and 
’’lookahead” during processing to determine when 
enough space will be available to enter the work¬ 
ing set. 

If the machine does it, a technique called 
’’demand paging” is used. In this case, the ma¬ 
chine loads pages while retaining previously 
loaded pages, and pages are swapped in and out 
as demands change. 

Both techniques result in a fair amount of 
system overhead even if the working set is intel¬ 
ligently specified. This could be improved sub¬ 
stantially if the working sets were analyzed to 
determine which instructions are used most 
frequently by the program. The technique em¬ 
ployed for such analysis is sometimes referred 
to as ”80-20, ” meaning that 20 percent of the code 
does 80 percent of the work. Obviously, if this 
code were placed on pages that were continuously 
core resident, greater overall efficiency would 
result (no seeks or page swapping would be re¬ 
quired) and the problem of thrashing considerably 
reduced. To have the programmer determine this 
could present substantial problems. A better 
method would be to construct a compiler routine 
to analyze and construct an optimal working set. 

No such routine, to our knowledge, exists. 

Another solution is program loop analysis, 
which is quite similar to working set analysis, 
eliminates the same problems, and results in 
similar efficiencies. Here the compiler breaks 
down the program into blocks of code and shows 
their interaction. The intent is to recognize loops 
and nested loops to allow simplification of the in¬ 
nermost loop. The compiler then rearranges the 
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code in a fashion to allow a loop to fit on 1 page 
(or more for a large loop) which would be core 
resident during loop execution. 

If virtual storage has ail these problems, you 
may be asking yourself, ’’Where does it fit?” 

That depends on the number and type of applica¬ 
tions you’re running, the size of your machine, 
and the attitude of your programming staff. 

If you run only a few batch applications on a 
small to medium machine, you may not need VS. 
However, you may need the other benefits offered 
by the virtual machines. 

If you’re running a large number of core eat¬ 
ers, you can certainly benefit from VS provided 
your programs are laid out intelligently to head 
off thrashing. This places a further burden on 
your programmers, however, and we don’t have 
to tell you what that means. 

If you’re running a large mix of teleprocess¬ 
ing and local batch, VS can be most beneficial 
since you don’t have to dedicate large portions of 
main storage to serve infrequent applications 
(such as teleprocessing). 

Real Storage Checkerboarding 

While it’s true that the need for large chunks 
of contiguous real storage to hold programs is 
unnecessary with virtual memory, the core 
checkerboarding problems that plague MFT and 
MVT have not been totally eliminated. Core 
checkerboarding can occur in real storage when: 

• the system queue area (SQA) and protected 
queue area (PQA) are too small. 

• the ’’long-term fix” area is poorly 
positioned. 

Real storage for the SQA is specified at 
SYSGEN or NIP time, and appended to the nucleus 
thus making it unavailable for V = R execution. If 
too little space is allocated, the system dynam¬ 
ically allocates more. This causes a checker¬ 
board because the extension is located in what the 
system deems an appropriate area. This area 
may not be optimum as far as V = R is concerned, 
however. An SQA extension, for example, might 
fall in the middle of the V = R area, in which case 
the contiguous available storage area would be 
cut in half. 

PQA’s problem is pretty much the same in 
that it also affects the V = R space. When a parti¬ 
tion is defined, at least 2K bytes of real storage 
are reserved for PQA for each partition. When 


more storage space is needed, the system ex¬ 
tends the PQA in 2K-byte increments. Like SQA, 
these increments are placed in what the system 
considers an optimum location. The resulting 
problem is the same also. 

The long-term fix problem, paradoxically, 
exists because a feature was added to solve a 
problem. Some components, you see, cannot tol¬ 
erate a page fault. To eliminate this possibility, 
certain pages can be fixed in real storage and 
cannot be moved within real storage or paged out. 
These pages, too, are fixed by the system in what 
it feels are optimum locations. The checkerboard 
is the same as for SQA and PQA. 

Job Entry Subsystem 

One of the truly notable features of VS1 is the 
Job Entry Subsystem (JES), a series of routines, 
which improve the overall management of periph¬ 
eral I/O operations. JES is a pageable reentrant 
reader program that spools and schedules any 
number of readers and writers — provided suffi¬ 
cient resources are available. MFT, on the other 
hand, supports 3 readers and 36 writers and these 
require partitions. JES readers and writers re¬ 
side in the JES area of storage and operate con¬ 
currently with jobs. 

JES operates with the system scheduler and 
contains many features of the Type III HASP pro¬ 
gram used with MFT. 

Essentially, JES performs 3 basic functions: 

• All primary input streams are read from 
the input device and stored on a direct ac¬ 
cess storage device (DASD) in a format 
convenient for later processing by VS1 and 
problem programs. 

• System (and selected user) print and punch 
output is similarly stored on DASD until a 
convenient time for producing a hard copy 
on a printer or punch device. 

• If system resources are in contention, JES 
schedules its activities to best utilize these 
resources. 

JES is responsible for getting jobs into and out 
of the system as quickly as possible to enhance 
system throughput and performance. It accom¬ 
plishes this by reading jobs into the system, di¬ 
viding them into various segments (job control 
statements and data, for example), and storing 
them. When the jobs are selected for execution, 
the JCL is interpreted separately. This procedure 
reduces the need for executing system reader and 
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interpreter functions sequentially when jobs are 
first read into the system, as in past operating 
system environments. 

During execution of a job, JES spools the out¬ 
put into a data set, that is, the data is stored on 
a DASD device in a manner that reduces the move¬ 
ment of the access mechanism. 

JES supports a Logical Cylinder function that 
provides the user with the ability to more effi¬ 
ciently use the DASD workspace that is allocated 
for spooling. JES also supports a Writer Check¬ 
point function that provides the user with the ca¬ 
pability of checkpointing the SYSOUT data sets. 

JES supports an Output Separator facility that 
provides a means of identifying and separating 
the output of various jobs that are processed by 
the same output device. It handles the checkpoint/ 
restart capability, thereby complementing other 
RAS facilities to ensure continuous operation. 

JES consists of 2 components: the Job Entry 
Peripheral Services (JEPS) and Job Entry Central 
Services (JECS). JEPS provides the functions of 
a system reader and writer. All VS1 inputs (ex¬ 
cept console entered commands) pass through the 
JES reader. 

All resource management for JES is consoli¬ 
dated in the Job Entry Central Services facility. 
JECS has 3 logical functions, each of which pro¬ 
vides a management service for JES: 

• Buffer Management — A central buffer 
handling facility for JES. 

• Spool Management — Has the responsibility 
to logically handle data such as JCL text, 

in line input data, procedure libraries, sys¬ 
tem messages, WTP, and spooled output 
data. 

• DASD Work Area Management — Suballo¬ 
cates DASD workspace and performs I/O 
operations on DASD workspace for JES. 

All other scheduler operations such as interpre¬ 
tation, allocation, command processing, initia¬ 
tion and termination of system and program 
tasks, data management, and system management 
facilities (SMF) interface with JES. 

Remote Entry Services 

A recently added enhancement to VS1 is the 
excellent remote job entry services (RES). RES 
is much like HASP II remote job entry, and per¬ 
mits jobs submitted locally and remotely to use 
the same job control statements and commands. 


RES accepts jobs from remote locations using 
binary synchronous communications. Output may 
be returned to the terminal from which it was 
submitted, to another remote terminal, or to the 
central printer facility. 

RES is a logical and functional extension of 
JES. It extends the JES functions so that remote 
users can be attached to VS1. Using RES, jobs 
can be submitted from remote terminals and out¬ 
put can be routed back to the terminals. RES 
makes VS1 available to teleprocessing terminals 
so that more users can have direct access to the 
central system for their job submission. 

RES provides all remote batch processing 
facilities. Using normal JCL (no special state¬ 
ments or parameters), the user can submit a 
job or a batch of jobs from his terminal directly 
into the system. He avoids the inefficient pro¬ 
cedure of putting the jobs together, submitting 
them to the computer center, having the operator 
enter the jobs into the computer, and waiting for 
his output to be processed on the same local 
facilities as the output from other users’ jobs. 

By using a true subset of system operator com¬ 
mands, the remote user can inquire about and 
manipulate his jobs. RES supports the following 
stand-alone work stations and features: 

• 1130. 

• System/3. 

• 2780 Data Transmission Terminal. 

• 2770 Data Communications System. 

• System/360 Model 22-195 CPU (Model 25 
requires ICA 4580). 

• System/360 Model 20. 

• System/370 Models 135 to 168 CPU in BC 
(Basic 360 Control) mode only. 

• System/370 Model 195 CPU. 

• Point-to-Point Leased Lines. 

• Point-to-Point Dialup Lines. 

• Line Error Recovery. 

RES requires a 2701, 2703, or Model 135 In¬ 
tegrated Communications Adapter (4640) equipped 
for binary synchronous communications. A 
minimum processor storage size of 144K bytes 
allows the use of 1 terminal subject to the re¬ 
strictions that apply to the 128K real storage de¬ 
sign point. However, to obtain more effective 
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function and performance, a processor storage 
size of 240K bytes or larger should be used. The 
real storage requirements are dependent upon 
the user’s definition of VS1 and the RES line and 
terminal configurations. 

Job Initiator 

The job initiator is another extremely signif¬ 
icant function of VS1. Under MFT, a certain 
amount of contention for initiators existed be¬ 
tween jobs. This is reduced under VS1 by split¬ 
ting off the control blocks on the job queues and 
providing each initiator with a separate work data 
set for initiation and termination. The net re¬ 
sult is that contention for the job queue is re¬ 
duced, and small partition scheduling should be 
more efficient. With VS1, up to 15 initiators 
can be started. 

The VS1 initiator is pageable and has no resi¬ 
dent modules. When the command is entered from 
the console specifying an initiator procedure, the 
initiating task is established in the specified 
partition to schedule job execution. The initiator 
job selection routine dequeues the highest pri¬ 
ority job from the first job input queue associated 
with its partition. 

A program required for execution is fetched 
from the program library and placed in virtual 
storage. It is paged as needed and execution be¬ 
gins after the entire program’s relative addresses 
(created by the linkage editor) are resolved into 
absolute virtual addresses. When the final step 
of the job is terminated, or if the job is bypassed, 
any temporary or deleted data sets are returned 
to the system and the initiator is ready to select 
another job. 

The VS1 interpreter operates as a subroutine 
of the initiator. Its function is to analyze the 
contents of job control statements and build ta¬ 
bles that are used during the initiation and exe¬ 
cution of job steps. 

The allocation function operates as a subrou¬ 
tine to the initiator. Its function is to analyze 
the I/O device requirements of job steps, allo¬ 
cate devices to them, issue volume mounting in¬ 
structions, and verify that the volumes are 
mounted on the correct device. VS1 allocation 
also supports dedicated data sets. The use of 
dedicated data sets reduces the time required to 
schedule a job step by eliminating the time nor¬ 
mally required for allocating prespecified data 
sets. 

When a job completes execution, the termina¬ 
tion routines free (deallocate) all resources used 


by the program and perform the necessary 
’’cleanup” operations to allow the system to con¬ 
tinue functioning for other problem programs. 

Virtual Storage Access Method 

Users may choose from the following types of 
access methods: basic sequential, basic direct, 
basic partitioned, basic and queued indexed se¬ 
quential, teleprocessing, and virtual sequential. 
Only the last is new. 

VSAM is a disc accessing method designed to 
be a functional replacement for ISAM. Essen¬ 
tially, VSAM offers extended functions relative 
to ISAM, coupled with improved performance and 
a new data set organization. Programs currently 
written to operate with ISAM can be converted by 
way of an ISAM interface routine and an ISAM-to- 
VSAM data set conversion facility to operate on 
VSAM data sets. No recompilation or link edit¬ 
ing is needed. 

VSAM is mode compatible with ISAM by rec¬ 
ognition of ISAM structure and automatic calling- 
in of interface routines. Hence, it is to the 
user’s advantage to eliminate this performance- 
degrading activity by converting his files to 
VSAM. 

VSAM is the standard accessing method used 
with OS/VS1, OS/VS2, and DOS/VS. New VSAM 
capabilities unavailable in ISAM include: 

• Mass sequential insert. 

• Skip sequential. 

• Sequential and direct processing with one 
open verb. 

• Multiple request processing (OS/VS only). 

• Data set sharing across partitions using 
track hold in DOS/VS, and within a region 
in OS/VS. 

• Device independence. 

• Portability of data sets between DOS/VS 
and OS/VS. 

• Variable length records, passwords, and 
catalog support for the DOS/VS user. 

Data portability between systems is possible 
because VSAM organization and access methods 
are supported by DOS/VS and VS1 and 2. 
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VSAM operates with direct access devices and 
supports both direct and sequential processing by 
means of either index keys or relative byte ad¬ 
dresses. Both fixed and variable length records 
are supported. 

VSAM indexing capabilities include: nondense 
indexing; index key compression; index replica¬ 
tion (optional); high-level index in main storage 
(optional); and low-level index with data (optional). 
Its cataloging capabilities comprise master and 
user catalogs for OS/VS and a master catalog 
for DOS/VS. 

The indexing method offered by VSAM employs 
nondense indexing and index key comparison. 
Nondense indexes do not point directly to individ¬ 
ual records but instead point to larger units 
called control intervals. A control interval is a 
logical division of space in a data set utilizing 
VSAM organization. Since control intervals may 
contain a number of records, the overall effect 
is to shorten the index size and thereby decrease 
index search time and minimize index updating. 

Index key compression is based on the fact 
that portions of each index key are significant, 
while other portions are redundant. Compres¬ 
sion removes the redundant characters and thus 
reduces the index size and search time. 

Optional indexing features include: 

• Having the index records written repeatedly 
to minimize rotational delay; this feature 

is called "replicating the index. " 

• Having the lowest level of the VSAM index 
adjacent to the data it controls. 

• Having the index on a different device from 
the data set. 

• Having the higher level of the index in 
main storage if sufficient buffer space is 
specified. 

Two significant improvements have been made 
to handle free space on disc: ISAM-like overflow 
chaining has been eliminated, and holes left by 
deleted records are automatically reclaimed. 

The latter is an apparent answer to the many 
complaints voiced by ISAM users about the 
wasted disc space that exists while awaiting the 
reshuffling of records to fill the holes. In the 
past, many disgruntled users have turned to 
Comress’s AMIGOS for relief from ISAM’s 
inefficiencies. 


The VSAM method for eliminating overflow 
chaining is worth noting. The concept is called 
"distributed free space" and works on a principle 
that requires certain partitions of VSAM control 
intervals and a specified number of extra control 
intervals to remain empty when the data set is 
initially created. Thus, inserts to the data set 
or changes to the length of existing records are 
accommodated by using the extra space. 

Virtual Telecommunications Access Method 

Three access methods are available to handle 
teleprocessing: the old BTAM, QTAM, and the 
new virtual telecommunications access method 
(VTAM). 

VTAM is an integrated system control pro¬ 
gram for DOS/VS and VS1 and 2. It provides 
for direct transmission of data between applica¬ 
tion programs and terminals. Using the network 
control program (NCP) mode of the 3704/3705 
Communications Controller, it makes the lines 
and the communications controller transparent 
to the application program. VTAM also: 

• Provides dynamic sharing of network re¬ 
sources (including terminals, lines, and 
3704/3705s in NCP mode) among VTAM 
teleprocessing application programs. 

• Provides telecommunications support for 
multiple teleprocessing application pro¬ 
grams in a virtual-storage environment. 

• Enables programs using VTAM and TCAM, 
as well as those using TSO, to execute con¬ 
currently in the same system and share the 
same network. 

• Makes certain VTAM facilities (for ex¬ 
ample, network sharing) available to pro¬ 
grams written for TCAM. 

• Provides a common base, with VSAM, for 
customer DB/DC systems. 

• Expands the basic telecommunication ser¬ 
vices available to the application 
programmer. 

c Aids in customizing and installing a tele¬ 
communications network. 

Program Interface. An application program 
requests VTAM’s services by first creating a 
control block that reflects the desired operation, 
and then issuing a macro instruction with a 
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pointer to this control block as its principal oper¬ 
and. Macros are provided to create VTAM con¬ 
trol blocks. 

Using the macro language, the program can 
interface with VTAM connection services to 
make and break connections between itself and a 
terminal, to receive notification if the operator 
breaks the connection, and to switch connections 
to other application programs. 

An application program can be connected to, 
and can communicate with, more than 1 terminal 
simultaneously. Using VTAM macroinstructions, 
an application program can solicit input from a 
group of terminals via a single request. Using 
the macro language, the program can interface 
with VTAM data transfer facilities to request the 
actual transfer of data once a connection has been 
established between the application and a termi¬ 
nal. I/O requests may also be canceled and 
verified by using these facilities. 

VTAM macroinstructions include: SOLICIT, 
READ, WRITE, and RESET. Application pro¬ 
grams can also specify parameters in VTAM 
control blocks to alter requested I/O operations. 

SOLICIT causes VTAM to obtain data from 
terminals and to store it in VTAM buffers. The 
data is moved to the application program’s work 
area when a READ is issued. 

READ causes the transfer of 1 block of data to 
the application program’s work area. 

WRITE causes a block of data to be written to 
a terminal. A READ automatically and immedi¬ 
ately follows a WRITE when the conversational 
option is used. 

RESET cancels outstanding I/O requests for 
the specified terminal or terminals. It may be 
issued at any time. 

Shared Networks . Under VTAM, network re¬ 
sources such as the 3704/3705 (in NCP mode), 
lines, and terminals can be shared among VTAM 
and TCAM telecommunications application 
programs. 

Programs share terminals on a connection 
basis; that is, a terminal not already connected 
to an application may be available to other appli¬ 
cation programs using VTAM. However, once 
a terminal is connected to an application pro¬ 
gram, it cannot communicate with another pro¬ 
gram until the first program has released the 
terminal. 


The degree of terminal sharing depends upon 
limitations imposed by the customer installation. 
Terminal sharing can be limited by using VTAM 
options, including user authorization exits, to 
restrict the connection of specified terminals to 
only selected applications. 

Terminal sharing can also be affected by use 
of VTAM log-on/log-off facilities. Unless re¬ 
stricted, any available VTAM-controlled termi¬ 
nal can connect with any specified application 
program or with a TCAM MCP. Connection can 
be initiated by the terminal (by way of the log-on 
facilities of VTAM) or by the application 
program. 

Several application programs can communi¬ 
cate with different terminals on the same multi¬ 
point line. Also, terminals, whether on point- 
to-point or multipoint lines, can communicate 
with any of the teleprocessing application pro¬ 
grams using VTAM in the CPU. Application pro¬ 
grams can use VTAM directly or indirectly by 
way of TCAM to obtain VTAM sharing capability 
for communications controllers, NCP-VSs, and 
lines. 

Diagnostics . Diagnostic aids include operat¬ 
ing system and internal VTAM traces, operating 
system dumps (augmented by some VTAM for¬ 
matting, on OS/VS only), the VTAM device diag¬ 
nostics program TOLTEP (Teleprocessing On- 
Line Test Executive Program), software error 
recording (for OS/VS only), and hardware error 
recording. In addition to the diagnostic aids, the 
modular design of VTAM facilitates debugging and 
maintenance. Recovery procedures include op¬ 
erating system software error recovery pro¬ 
grams (for OS/VS only) and hardware error re¬ 
covery programs, as well as IBM 3704/3705 re¬ 
covery aids. 

TOLTEP is a component of VTAM and controls 
the selection, loading, and execution of telepro¬ 
cessing on-line terminal tests (OLTTs) for all 
control units and terminals in a VTAM network. 

It uses VTAM capabilities for line sharing, re¬ 
mote reporting, and remote test requests. 
TOLTEP performs control services, device ac¬ 
cessing, and configuration-update functions for 
teleprocessing OLTTs of devices supported by 
VTAM. 

TOLTEP does not support the dedicated test¬ 
ing of a locally attached 3704/3705 Communica¬ 
tions Controller. Dedicated testing of the local 
3704/3705 is handled by OLTEP. 
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Compatibility . Programs written in BAL, 
Cobol, or PL/1 that worked with TCAM will con¬ 
tinue to work when the TCAM message control 
program (MCP) communicates through VTAM. 

The interface between TCAM application pro¬ 
grams and the MCP remains the same in the 
VTAM environment. 

TCAM MCPs must be reassembled. For 
MCPs, a new parameter is required in the INTRO 
macro instructions if an MCP uses VTAM to sup¬ 
port locally attached 3270, in a network that does 
not have a 3704/3705 in MCP mode. The new 
parameter is not required if an MCP supports the 
locally attained 3270s without going through 
VTAM. 

Except for TCAM, VTAM does not affect the 
function of other telecommunications access 
methods (BTAM or QTAM) or of I/O subsystems 
(Power, RES, JES2 or JES3). VTAM shares net¬ 
work resources only with programs using the 
telecommunications access methods VTAM and 
TCAM. Except in the case of PEP, network re¬ 
sources controlled by VTAM must be separate 
(though they can be within the same operating 
system) from those not controlled by VTAM. A 
single application program may use both BTAM 
and VTAM to support separate telecommunica¬ 
tions networks provided that all of the require¬ 
ments of both access methods are met. 

Terminal Support . VTAM supports locally 
attached IBM 3270 Information Display Stations 
as well as 3704/3705 Communications Controllers 
in NCP mode. It does not support the 2260, 

2715-1 (2790), or the 7770-3. 

Remote terminals are attached through a 
3704 or 3705 and operate in a switched or non- 
switched network. These terminals include: 

• 1050 on a switched or nonswitched network. 

• 2740 Communication Terminal Model 1 on a 
switched or nonswitched network, with or 
without checking, and with or without sta¬ 
tion control or transmit control. 

• 2740 Communication Terminal Model 2 on 
a nonswitched network, with or without 
checking, and with or without the Buffer 
Receive feature. 

• 2741 Communication Terminal on a switched 
or nonswitched network. 

• Communicating Magnetic Card Seiectric 
Typewriter on a switched network (2741 
terminal support only). 


• AT&T 83 B3 Selective Calling Stations on 
a nonswitched network. 

• AT&T Model 33 or 35. 

• System/7 Processor Station in switched or 
nonswitched network. 

System Configuration . VTAM operates on 
System/370 Models 125, 135, 145, 155II, and 
158. VTAM requires a system with at least 96K 
bytes of real storage. 

Binary synchronous terminals support on 
switched or nonswitched networks are: the IBM 
2770, 2780, 3735, 3740, 3780, System/3 CPU, 
System/370 as a remote station, 2972 Models 8 
and 11, and the 3270. 

Scheduling Considerations 

VS1 and 2 retain the excellent scheduling 
technique employed by their parents, namely, 
job class and numeric or a combination of both. 
This feature is outstanding for it ensures that 
the important jobs can be placed in a higher pri¬ 
ority queue and assigned a high numeric pri¬ 
ority within the queue. 

By going to virtual storage, VS1 and 2 solve 
a significant drawback, namely, no job could be 
scheduled until sufficient contiguous core was 
available. Consequently, scheduling delays of 
important jobs could occur, or a fairly efficient 
job mix might have to be interrupted to provide 
the resources needed by a high priority job. 

Since the pages in real core need no longer be 
contiguous, this problem should just about 
disappear. 

VS1 and 2 however still carry over an old 
MFT-MVT weakness, namely, a job can begin 
processing without having enough resources 
available to allow it to run to completion. This 
is further compounded by the system’s inability 
to look ahead to ensure that resources will be 
available when needed. 

This poses a scheduling problem for the user. 
In a multiprogramming environment, for ex¬ 
ample, all jobs of equal priority compete for re¬ 
sources on an equal footing. The first job to 
gain control holds it. In the meanwhile, jobs 
which could be using needlessly held resources 
must wait until the owner job releases them; 
hence, processing delays can occur. 

Time Slicing 

The time-slicing capability offered is, in our 
opinion, one of the best available. With this 
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facility the user can establish a group of parti¬ 
tions or tasks (called a time-slice group) that 
are to share the CPU for the same fixed interval. 

A job T s priority can be changed so that it fails 
within the range of the priorities for the parti¬ 
tions defined for time-slicing. This job will 
then be handled in the same manner as the other 
jobs in the time-slice group. 

When a member of the time-slice group has 
been active for the fixed interval of time, it is 
interrupted and control is given to another mem¬ 
ber of the group, which will, in turn, have con¬ 
trol of the CPU for the same length of time. 

Only partitions that are assigned to the time- 
slice group will be time-sliced only when the 
first partition in the group is the highest priority 
ready task. Dispatching of the partitions con¬ 
tinues within the group until all the partitions are 
in a waiting state, or until a partition with a 
higher priority is in a ready state. 

The tasks to be time-sliced (selected by pri¬ 
ority or partition range) and the length of the 
time slice are specified at system generation 
time. This can be modified through the DEFINE 
command. Any task or partition in the system 
not defined within the time-slice group is dis¬ 
patched under the current priority structure; that 
is, the task or partition is dispatched only when 
it is the highest priority ready task or partition 
on the TCB queue. The maximum amount iof time 
each ready task can have control of the CPU dur¬ 
ing 1 pass through the group ranges from 20 msec 
to 9,999 msec. 

Record Handling 

There are some significant differences in the 
way VS1 handles records. For example, in 
MFT all SYSIN blocking factors are selected pri¬ 
or to job initiation, and BSAM users must either 
write code to accommodate the block sizes se¬ 
lected or explicitly override JCL. Under VS1, 
the system does the blocking. For BSAM inter¬ 
face, records are dynamically reblocked to user 
requirements during execution. 

In addition, no SYSIN support is provided for 
update or for overlaying or adding to data. SYSIN 
support for variable length records is also not 
compatible. Under MFT, block and record de¬ 
scription fields must be part of the input card 
image. With VS1, the entire 80-byte image is 
treated as data and block and record description 
fields are prefixed to it. Although blocked and 
unblocked records are supported, spanned rec¬ 
ords are not. 


If QSAM is used, all SYSIN records must con¬ 
tain 1 logical record for each original 80-byte 
card image. Cards cannot be divided into multi¬ 
ple logical records or combined into a single log¬ 
ical record except by BSAM with user deblocking 
routines. 

I/O Device Testing 

A standard test facility is provided by VS1 that 
allows 1/O devices used with running jobs to be 
tested on-line. Called OLTEP (On-Line Test 
Executive Program), it directs the selection, 
loading, and execution of the On-Line Test Sec¬ 
tions (OLTS). 

Together, the OLTEP/OLT system: 

• Diagnoses I/O errors. 

• Verifies I/O device repairs and engineer¬ 
ing changes. 

• Exercises a device requiring dynamic 
adjustments. 

• Checks the operation of I/O devices. 

• Verifies the integrity of customer data. 

OLTEP operates as a job and is called by 
standard job control statements. It operates 
under control of the operating system at all times 
and uses the system facilities to accomplish the 
tests. It competes with other jobs in the system 
for the use of system facilities when running in 
a multiprogramming environment. 

Definition of test runs can be entered by con¬ 
sole or nonconsole devices. Prompting is avail¬ 
able on consoles to assist in defining tests to be 
run. 

IBM supplies OLTS on magnetic tape or 
cards. The OLTS must be reformatted and link 
edited into a partitioned data set in order to be 
used under the operating system. 

OLTEP must normally be executed in the non- 
pageabie (virtual=real) area of real storage. It 
requires a minimum virtual partition of 64K and 
36K bytes of real storage. The log-out analysis 
program, which runs under OLTEP similar to an 
OLT, does not require virtual=real storage. 

Telecommunications Option 

The telecommunications option supplied by 
VS1 is comprised of 2 access methods: BTAM 
and TCAM. BTAM provides the basic facilities 
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needed to process telecommunications (for ex¬ 
ample, polling, code translating, error handling, 
etc.). VS1 BTAM supports the same functions 
as OS BTAM and requires no additional program¬ 
mer training. 

VS1 TCAM also supports the same functions 
as its OS counterpart, but runs as a subsystem 
in a virtual partition. Certain TCAM elements, 
such as the buffer pool, I/O appendages, control 
blocks, and tables are fixed in real storage for 
the duration of the TCAM task. 

Time-Sharing Option 

The time-sharing option (TSO) of VS2 adds 
general-purpose time sharing to the VS2 control 
program. The installation can dedicate the sys¬ 
tem to time-sharing operations, or it can run 
concurrent time-sharing and batch operations. 

TSO adds a number of capabilities to the fa¬ 
cilities already available through the VS2 control 
program. For example, it gives user access to 
the system through a command language entered 
at remote terminals — typewriter-like keyboard- 
printer or keyboard-screen devices connected 
through telephone or other communication lines 
to the computer, and provides those who may not 
be programmers the use of data entry, editing, 
and retrieval facilities. 

It also makes the facilities of the operating 
system available to programmers at remote ter¬ 
minals to develop, test, and execute programs 
conveniently, without the job turnaround delays 
typical of batch processing. (Both terminal-ori¬ 
ented and batch programs can be developed at ter¬ 
minals. ) TSO allows the management of an in¬ 
stallation to dynamically control the use of the 
system’s resources from a terminal. 

TSO consists of control routines, service rou¬ 
tines and command processors, and a number of 
IBM program products. All the facilities avail¬ 
able with TSO in MVT are available with TSO in 
VS2. VS2 enhances TSO in the following ways: 
it allows more foreground regions, and it allows 
the installation to place frequently used TSO 


commands or service routines in the pageable 
link pack area or TSO link pack area without re¬ 
ducing the amount of real storage available. 

When TSO is not active, the TSO LPA does not 
require address space. In addition, the paging 
supervisor, which does all swapping, uses 
external page storage for swapping, thereby 
eliminating the swap data set. 

TSO in VS2 differs from its MVT counterpart 
in several respects: 

• The number of regions that can be assigned 
to foreground jobs is increased from 14 for 
TSO in MVT to 42 for TSO in VS2. 

• The paging supervisor executes all swaps. 

• The LSQA is no longer taken from the re¬ 
gion; each TSO region is allocated 1 seg¬ 
ment of LSQA. 

• Swapping is now a process by which the 
valid pages (addressable pages) in a user’s 
region are usually block paged to external 
page storage and always block paged from 
external page storage. 

• Background regions must have 100 percent 
backup in external page storage. For ex¬ 
ample, a background job that requests a 
128K region is allocated 128K (32 pages) of 
external page storage as backup. 

• Most TSO jobs do not continually need an 
amount of external page storage equivalent 
to the region sizes requested. Conse¬ 
quently, foreground jobs are backed up by 
an installation specified amount of external 
page storage that is a percentage of the 
total amount of external page storage 
required. 

HEADQUARTERS 

IBM 

1133 Westchester Avenue 

White Plains NY 10604 
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GENERAL 

Disk Operating System/Virtual Storage (DOS/ 
VS), officially announced on August 2, 1972, is 
a greatly enhanced version of oft-maligned Sys¬ 
tem/360 DOS. Intended for the System/370 models 
upward through the Model 158 (but not the 155), 
the new operating system offers the following 
enhancements over its 360 counterpart: 

• Support of virtual storage of up to 16 
million bytes divided into 64K-byte seg¬ 
ments (on external storage) and 2K-byte 
pages. 

• Increased problem program partitions from 
3 to 5. 

• Ability to specify the dispatching priority 
of a partition at SYSGEN and alter it at 
IPL time and during system operation. 

• A relocatable loader, thus allowing pro¬ 
grams to be loaded and executed in any 
partition and with any size supervisor. 

• Spooling of I/O via IBM’s Power spooler. 

• Cataloging sets of job control cards on 
direct access storage. 

• Terminal support via the Virtual Terminal 
Access Method (VTAM) and customer 
information control system (CICS). 

• A multiple timer facility. 

DOS/VS also includes a new assembler, which 
supports all new System/370 instructions; a new 
data accessing method, VSAM; a new linkage 
editor; new libraries and system utilities; and 
diagnostic aids, such as OLTEP. 

DOS/VS is not an entirely new operating sys¬ 
tem; it T s a greatly enhanced version of DOS Re¬ 
lease 26. As such it retains many features of 
its parent — e. g. , multitasking, buffer allocation, 
recovery processing, etc. , are still the same. 

This report points out and elaborates on the 
enhancements and differences between the 2 
systems. 

Virtual Storage Concept 

The most talked about feature incorporated into 
the operating systems introduced to support the 
new versions and new models of the System/370 
is virtual storage. 


Virtual storage amounts to nothing more than 
using high speed discs or drums to provide inex¬ 
pensive expansions to the main processor. Please 
don’t make the mistake of thinking that virtual 
storage means: ’’virtually the same as real mem¬ 
ory. ” Virtual means: in essence or effect, but 
not in fact . Virtual storage, then, is an adjunct 
to real memory, and a slow one at that. 

The use of virtual storage — according to 
marketers — allows programs normally too large 
to fit into available core partitions or regions to 
’’get a shot” at the CPU. Also, since the pro¬ 
grammer need no longer concern himself with 
the size program, he can concentrate on the 
problem— that’s what the marketers say. There’s 
a lot about virtual storage they don’t say; read 
about it under DESCRIPTION AND EVALUATION. 

In case you’re not familiar with virtual mem¬ 
ory (or virtual storage as IBM calls it) termi¬ 
nology, storage is classified as being real or 
virtual. Real storage is the computer’s internal, 
physical storage; virtual storage is the application 
of a high speed direct access device (disc or 
drum) as if it were main processor storage. 
Programs may run in a purely real mode, purely 
virtual mode, or a combination of both. 

To understand the interaction of virtual and 
real storage some reorientation in your concept 
of main storage is necessary. First of all main 
storage is called real, while the back up high 
speed storage is called virtual. The sum of the 
real storage plus that allocated for virtual use is 
called the virtual storage system. 

For example a virtual system may be 20OK 
bytes long with 75K being real storage. That part 
of the virtual storage that can be directly equated 
to real storage is called the real address area. 
Here it is zero to 75K. 

That part beyond the end of the real address 
area, up to the limit of the virtual storage de¬ 
clared at system generation, is the virtual ad¬ 
dress area. In this case it's 76K to 200K. A 
more detailed treatment of how storage is allo¬ 
cated and controlled is found under Main Storage 
Allocation . 

Storage addresses up to the logical limit of 
the system’s addressing structure (16,777,216 
bytes in System/370) can then be directly used by 
programs independent of the actual size of system 
main storage. In order to do this, the processor 
must maintain and use an address translation 
table that is capable of automatically mapping 


97 




IBM — SYSTEM/370 DOS SYSTEM/VS, RELEASE 27 


addresses from backing virtual memory into 
main store. This is called dynamic address 
transition. (See Program Loading.) 

Operating systems for virtual memory assume 
additional responsibilities, the most important of 
which is management of the real memory re¬ 
source. This is called mapping, the procedure 
of maintaining a one-to-one correspondence list 
of virtual memory addresses on backing store 
versus real main storage locations. 

Virtual memory can be paged or segmented. 
IBM uses the former method. Paging breaks the 
virtual store into multiple fixed and equal-size 
blocks (pages), which are then brought into real 
memory as needed. Real memory assumes the 
role of a page frame. With IBM, the page frame 
and page size is a 2K or 4K bytes. 

The concept of a partition, as had existed 
under earlier IBM operating systems now applies 
only to virtual memory space. There, pages 
belonging to a program are contiguous; in real 
memory, page locations are random, with the 
new operating system providing linkage. 

Paged memory does allow extremely large 
programs to run. For all practical purposes, 
in fact, partitions in virtual store can be as large 
as needed. 

Virtual storage is possible under S/370 archi¬ 
tecture due to dynamic address translation, ex¬ 
tended control mode operation, and channel 
indirect addressing. 

Extended Control (EC) mode provides an 
extended format for the processor's program 
status word (PSW), thereby gaining control over 
several System/370 functions unavailable in the 
previously used basic control mode. 

Channel Indirect Data Addressing allows a 
single channel control word (CCW) to span several 
pages in noncontiguous real storage during I/O 
data transmissions. For each CCW that potenti¬ 
ally spans a page boundary, the channel control 
program will automatically generate an indirect 
address list. This facility is different from data 
chaining, which requires a unique CCW for each 
data address noncontiguity and also must be 
consciously programmed. 

The chief drawback of paged virtual memory 
is that a system could require page swaps be¬ 
tween memory and virtual store at such a rate 
that the system is overwhelmingly preoccupied 
with paging to the exclusion of useful work. This 
activity is called T 'thrashing. Tt IBM attempts to 
prevent thrashing in 3 ways: by selection of a 


page size appropriate to the operating system; 
through the use of a priority scheduling algorithm 
that allows paging of only the highe st-priority 
jobs in the event that thrashing begins; and by 
allowing the user to select the most advantageous 
combinations of CPU power, real store size, and 
device type used for virtual store. 

When a page must be called in and all real 
memory page frames are filled, a "page fault" 
is encountered, and the new page called in re¬ 
places the least recently used page in real mem¬ 
ory. IBM further reduces interference due to 
paging by providing 2 additional bits associated 
with each real memory page frame. One is a 
use bit and one a change bit. If the page to be 
replaced has not been changed during its use, it 
is not written out to external page store, but is 
simply overwritten in real memory by the new 
page brought in. 

It should be pointed out that theoretically any 
system could implement virtual memory in soft¬ 
ware. All that needs to be done is to apply traps 
for addresses and create a reference table and 
mapping program. When important functional 
aspects of such a system are hardware imple¬ 
mented, a manufacturer can more validly claim 
to have developed a virtual memory system. 

Users shouldn T t allow themselves to be "wowed" 
by buzzwords like virtual memory. They should 
also remember that the direct access backing 
store for virtual store implementation is 3 to 5 
orders of magnitude slower than a computer's 
main store. 

Another point should be made clear to users 
of virtual memory systems, namely, the execu¬ 
tion time for a specified job in a virtual system 
is likely to be longer than in a nonvirtual system. 
The advantage presented by the virtual system is 
in multiprogramming efficiency, for total system 
throughput. The problem that IBM is addressing 
is that the jobs which could have rim quite nicely 
on the nonvirtual system often could not, in real 
life, get on the system to run. 

Program Construction 

No radically new programming techniques are 
required for DOS/VS, except maybe that the pro¬ 
grammer should layout his job so that the more 
frequently called routines will ultimately appear 
on contiguous pages. This process should reduce 
the number of page faults and thus lighten the 
overhead load associated with a paged system. 

The amount of work required to construct a 
program to run under DOS/VS varies directly 
with the amount of real storage available. An 
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abundance allows the programmer to be more 
casual in overall program planning; the opposite 
applies when the "real thing" is in short supply. 

Like with 360 DOS, users have the option of 
constructing programs as either simple struc¬ 
tures, planned overlays, or dynamic structures. 
The program steps, required to produce a 
process able program are shown in Figure 1. 

After a program is assembled or compiled, it 
is link edited for a virtual partition or the user 
may specify link editing for relocatable loading 
into any real or virtual partition. The linkage 
editor places all phases of a program into the 
core image library. 

The linkage editor service program remains 
one of the critical components of the DOS. All 
programs executed under DOS must be edited by 
the linkage editor before execution is possible. 
The program combines object modules supplied 
in the job input stream, newly compiled object 
modules, and object modules from the relocatable 
library. It edits the modules into executable 
programs. These programs then can be fetched 
directly from the link-and-execute file (a tem¬ 
porary part of the core image library) or they 
can be cataloged into the core image library. 

All programs except self-re locating assembly 
language routines must be link edited for each 
change of core configuration. 

Execution of programs under DOS is a 3-phase 
process including compilation by a language 
processor, linkage editor functions, and loading 
of the program phase(s) by the system loader. 

The output of the linkage editor, called a 
program phase, is that section of a program 
which is loaded as a single overlay with a single 
FETCH or LOAD by the system loader. Pro¬ 
grams can consist of many phases, the first 
fetched by job control and each of the following 
by a preceding program phase. 


Program Loading 

A program is loaded for execution by trans¬ 
ferring pages from the core image library to 
real storage. If sufficient page frames are not 
available in real storage, pages are paged out 
to the Page Data Set until the entire program is 
loaded. The capacity of the Page Data Set is 
equivalent to the size of the system T s virtual 
address area. The loading procedure is shown 
in Figure 2. 

During execution, referenced pages not in 
real storage are retrieved from the Page Data 
Set. If the contents of a page in real storage 
have been altered or a duplicate copy of a re¬ 
placed page does not exist, the page is trans¬ 
ferred to the Page Data Set before the new one is 
brought in. 

The called page is located and transferred into 
real storage via a Dynamic Address Translation 
(DAT) procedure. DAT provides an automatic 2- 
level address translation and mapping process 
that utilizes page and segment tables to yield an 
effective storage address span of 16,777,216 bytes 
(16 megabytes). Segments on external page store 
of 64K or 1 million bytes are broken into pages 
of 2K in the case of DOS/VS and VS1 or 4K bytes 
in the case of OS/VS2 (K = 1,024 bytes). 

Page addresses are treated as logical ad¬ 
dresses, and the translation develops the real 
address. The address translation part of the 
process is hardware implemented; page mapping 
is under supervision of the operating system. 

The translation and mapping process is trans¬ 
parent to the user, who simply operates with 
the usual logical address structure. 

An associative array, which is an 8-entry 
buffer that holds the most recently used main 
storage addresses, is used for this special pur¬ 
pose instead of main memory to increase the 
speed of virtual memory access and lessen CPU 
interference caused by paging. 



Figure 1. DOS/VS: Program Development Stages 
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Main Storage Allocation 

Storage is allocated to handle both real and 
virtual addresses. 

Real Storage. Real storage is used for super¬ 
visor routines, Power, teleprocessing, real 
address partitions, and execution of programs 
from the virtual address area. 

Portions of the real address area are allocated 
the partitions defined during system generation. 
Five partitions can be generated: background, 
foreground-4, foreground-3, foreground-2, and 
foreground-1. Processing priorities are back¬ 
ground, lowest, through to foreground-1, highest. 
The user may change these priorities at SYSGEN 
or the operator can do it between job steps. 

Programs are loaded from a core image 
library into the real address area allocated to 
the partition and executed there. This allocated 
portion of the real address area is called a real 
partition and the program loaded there runs in 
real mode. Programs running in real mode 
cannot exceed the limit of their real partition. 

Virtual address processing is an alternative 
to running a program in real mode. Instructions, 


however, must be physically resident in real 
storage to be executed; DOS/VS assumes the re¬ 
sponsibility for placing the code from the virtual 
address area into real storage for execution. 

Virtual Storage . Virtual address areas must be 
allocated for all active partitions regardless of 
whether user programs running in them will 
execute in real mode or virtual mode. The mini¬ 
mum virtual partition size is 64K bytes. 

Conceptually, virtual mode means that when 
a program is loaded from a core image library 
for execution, it is loaded into the virtual ad¬ 
dress area allocated to the partition. The virtual 
address area allocated to a partition is called the 
virtual partition. Virtual partitions are also 
declared at SYSGEN. For actual program execu¬ 
tion, DOS/VS then places the program, or sec¬ 
tions of it as required, into real storage. 

Storage Management. Storage is assigned ac¬ 
cording to partition priority and storage require¬ 
ments of each program at different stages of its 
execution. The system can also temporarily 
suppress one or more programs when there is 
not enough real storage to support all programs 
running in virtual mode at a reasonable level of 
performance. The more real storage available 
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Figure 2. Program Loading in Virtual Mode 



for this storage management activity, the higher 
the percentage of the installation’s programs 
running in virtual mode. 

When the limitations of real storage prevent 
all programs running in virtual mode from being 
simultaneously present in real storage, DOS/VS 
exchanges pages between the Page Data Set and 
real storage as they are required for execution. 
The area of real storage into which the system 
loads a page is called a page frame. All the real 
storage page frames into which pages from any 
program running in virtual mode may be brought 
for execution make up the page pool. 

The page pool can dynamically change in size 
as the system runs. Real storage contributing to 
the size of the page pool at any moment is made 
up of: (1) real storage not used by the supervisor 
and not allocated to partitions. This must be at 
least 16K bytes unless all programs are running 
in real mode. In this case it may not be required 
at all. (2) Real storage allocated to a partition 
when the program in that partition is running in 
virtual mode. In this case, the program is con¬ 
sidered to be occupying the virtual address area 
of the partition, leaving that portion of real 
storage to the page pool. 

Any real storage allocated to a partition in 
excess of that actually required by the program 
currently running in real mode also becomes part 
of the page pool. For example, if a 40K-byte 
program is running in real mode in a 54K real 
address area of a partition, the surplus 14K bytes 
can be made available to the page pool. 

Job Streams 

Job streams are usually built for execution in 
a specific partition. Each program executes 
either in real mode or in virtual mode, and each 
partition may have parts of both the real and 
virtual address areas allocated to it. Each par¬ 
tition must have part of the virtual address area 
allocated to it in order to contain certain of the 
IBM system programs, such as job control, which 
run in virtual mode. As was previously noted, 
the minimum virtual partition allocation allowed 
by the system is 64K. Therefore each partition 
must have at least 64K of virtual address area. 

Libraries 

Four libraries are offered to allow programs 
to be stored on line: core image, relocatable, 
source statement, and procedure. 

The core image library catalogs the program 
phases that have been processed by the linkage 
editor and are ready for loading. Phases can be 


in either nonrelocatable or relocatable format. 

A nonrelocatable phase is loaded directly at the 
address computed at link edit time into a real or 
virtual partition. 

The relocatable loader — one of the most wel¬ 
come enhancements offered by DOS/VS — allows 
the linkage editor to produce relocatable phase. 
Here, the load addresses, entry points, and the 
address constants of these phases are modified 
by the relocating loader, and phases can, there¬ 
fore, be loaded at storage addresses different 
from the ones for which they were link edited. 

The relocatable library contains object mod¬ 
ules that can be executed from any storage loca¬ 
tion. When link editing is performed, these 
modules can be combined with other program 
modules. Hence, frequently used routines can 
be kept in residence and included in any phase 
when needed, without recompiling or reassem¬ 
bling them. 

The source statement library, for the most 
part, extends the functions of a macro-code 
library and contains sequences of source language 
statements. These sequences are called books, 
and only complete books (not individual records) 
can be added to or deleted from the library. 

If the assembler encounters a source statement 
with an unknown operation code, it retrieves the 
book with the same name as the unknown operation 
code from the source statement library. When a 
compiler encounters a reference to a book, it too 
retrieves it from the library and substitutes it 
for the reference in the source program. 

The procedure library simply catalogs fre¬ 
quently used data sets of job control and linkage 
editor statements. 

The private libraries allow users to construct 
private core image, relocatable, and source 
statement libraries. 

Language Translato rs 

The language translators offered are RPG II, 
Fortran F, Cobol (ANS Versions 1 and 3), and 
PL/1. Assembler language programming, avail¬ 
able with 360 DOS, has been dropped. Programs 
written in Cobol D and RPG will run under DOS/VS 
with some changes (see Compatibility). 

The RPG II is an expanded version of the pre¬ 
vious language offered with DOS, and is reported 
to be easier to use, more flexible and more 
powerful than the original RPG offering. The 
Fortran compiler supplied is the F-level. 
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The Cobol compilers offered are the full ANS 
version and a subset ANS Cobol. The full com¬ 
piler, called Version 3, incorporates improve¬ 
ments that reduce the size of the object modules, 
plus offers extensive debugging facilities, alpha¬ 
betized cross reference lists, and ASCII support. 
This compiler requires at least a 54K-byte 
partition and the use of the Object library 
Program Product. 

The subset ANS compiler, called Version 1, 
supports Level 2 of the National Bureau of 
Standards together with the features from higher 
levels. This subset is more powerful than Cobol 
D and adheres to ANS standards. Programs 
written for this subset can also be compiled by 
the full ANS Cobol Compiler. Version 1 needs a 
20K-byte partition to run. 

PL/1 support is handled by a new optimizing 
compiler, and 2 object time libraries: resident 
and transient libraries. The compiler, in addi¬ 
tion to optimizing code, provides a high level of 
PL/1 and diagnostics at both compile and object 
times. 

The language level implemented contains ex¬ 
tensions beyond the PL/1 D- and F-level subsets. 
However, /source programs written for the PL/1 D 
can be compiled by the new compiler, or the 
PL/1 D compiler itself can be run under DOS/VS. 

The 2 object time libraries are required to 
execute the object modules produced by the opti¬ 
mizing compiler. These libraries contain sub¬ 
routines that must be combined with the object 
modules to produce executable programs and 
other subroutines that are required dynamically as 
the object program is being executed. 

DOS/VS also offers an interactive terminal 
facility (ITF), supported by 2 languages: ITF- 
Basic and ITF-PL/1. The latter is a subset of 
conventional PL/1. 

Emulators 

DOS/VS allows the user to emulate the 1401, 
1440, 1460, 7010, and the System/360 Model 20. 
The emulative and System/370 supporting it are 
shown in Table 1. 

When running under 1401/1440/1460 and 1410/ 
7010, all disc files must be converted (unless the 
CS30 or CS40 compatibility options are used). 

Tape programs, however, can be in original 
format (the DOS spanned variable record format 
is set as standard for the 370 emulators). 


Table 1. Emulative Under DOS/VS 


Emulation 

Mode 

Emulation Model 

115 

125 

135 145 

155H 

158 

1401/1440/1460 

V 

V 

V V 

V 

V 

1410/7010 



V 

V 

V 

S/360, Mod. 20 

V 

V 

v/ 




If the Model 20 emulator is being run, mixed 
parity/density on 7-track tapes is not supported, 
and the load UCS is performed by a DOS/VS 
utility (instead of a Model 20 utility). 

Compatibility 

Current DOS data files can be processed by 
DOS/VS, provided compatible I/O devices are 
used. Programs written for a 2311 can be pro¬ 
cessed on a 3333 or 3330 attached to a System/ 

370 Model 125 through the use of the 2311 Com¬ 
patibility Feature and the Model 115 via a pseudo 
2311 compatibility feature. Programs written 
for the 1052 Console Printer-Keyboard can be 
processed on the video display and 5213 Console 
Printer of the Model 115 and 125 through the use 
of the 1052 Compatibility Feature. 

Existing assembler language source programs 
can be assembled by the DOS/VS Assembler, pro¬ 
vided that no user written macros are called. If 
they are, the user must either supply COPY in¬ 
structions for the macro definitions at the begin¬ 
ning of all source decks in which the macros are 
used, or convert his library macros to edited 
macros and include them in the macro sublibrary. 

High level language source programs can be 
compiled if the appropriate compiler is available 
for DOS/VS. Cobol D programs must be changed 
or converted with the Language Conversion Pro¬ 
gram before they can be processed by an ANS 
Cobol compiler. RPG programs must be adapted 
to RPG II. 

Previously compiled or assembled DOS object 
programs can be link edited without modification 
under DOS/VS. User programs will execute pro¬ 
vided the following points have been taken into 
account: 

• Programs referencing supervisor control 
blocks or manipulating data in the super¬ 
visor area of the first 512 bytes of storage 
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(including specific bits such as the former 
PSW ASCH bit) may not run properly with 
DOS/VS. Because these areas are subject 
to change, user program compatibility can 
be protected only when user written routines 
employ STXIT and other appropriate EBM 
macro instructions. 

• Devices specified by the program must be 
available on the system on which DOS/VS 
will run. 

• Programs that depend on CPU circuitry not 
supported on System/370 may not execute 
properly. 

• Proper processing of time dependent pro¬ 
grams run under earlier versions of DOS 
is not ensured. 

• Programs that deliberately create program 
checks may not run properly. 

« User written I/O appendages must either 
run in real mode or adhere to certain DOS/ 
VS restrictions. Programs with self¬ 
modifying channel programs must run in 
real mode. 

Also, since the DOS/VS supervisor will gener¬ 
ally be larger than its DOS counterpart, programs 
in most cases will have to be relink edited if they 
were not written as self-relocating. 

Configuration Requirements 

The minimum peripheral configuration for DOS/ 
VS are one DASD (2314, 2319, 3330, 3340), one 
system console (3210, 3213, 3215), one printer, 
one card reader, and one punch (optional). 

The intermix of 3330 and 3340 disc subsystems 
can be attached to either the 3830-2 storage con¬ 
trol or integrated storage controllers (ISC) and 
integrated file adapters employed with some 
S/370 f s. Although the intermix capability is pro¬ 
vided at no extra cost, a control storage extension 
is required. On the 3830-2, the extension rents 
for between $395 to $470 each month (depending 
on the User Plan), while the ISC version goes 
for $300 each month. Purchase price is $18,800 
for the 3830-2 extension and $14,400 for the ISC. 

The intermix feature will be important to users 
who already have a 3330 capability and want to 
add 3340’s. 


Real storage requirements vary with the super¬ 
visor. They are: 

• Model 115 - 26K bytes. 

• Model 125 - 24K bytes. 

• Model 135 - 28K bytes. 

• Model 145 - 26K bytes. 

• Model 155II - 30K bytes* 

• Model 158 - 3OK bytes. 

These are minimum figures, mind you. To do 
any worthwhile processing, the minimum real 
storage would be about 96K bytes. 

FUNCTIONAL CHARACTERISTICS 

Job Types 

Batch and teleprocessing. 

Job Scheduling 

Serially by partition; jobs serviced first in, 
first out (FIFO); priority scheduling permitted 
with optional Power spooler. 

Resource Allocation 

Main Storage: fixed size partitions (real and 
virtual); variable size page pool. 

CPU Time: indefinite time assignment. 

I/O Devices: discs are shareable among par¬ 
titions; unit record devices and tapes are statically 
assigned to the partition. 

Information Files: statically assigned; shared 
via VSAM; re ad/write-only access; nonreusable, 
serially reusable, relocatable. 

Program Structure and Loading 

Simple structures, planned overlays, or 
dynamic structures divided by the system in 2K- 
byte pages. Object modules link edited immedi¬ 
ately or stored in relocatable module library for 
link editing later. 

I/O Control 

Device Types: disc, magnetic tape, type¬ 
writer, unit record devices. 
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Buffer Allocation: user specifies single, 
double, or exchange. 

Remote Terminal Support: standard terminal 
speed and format; supports basic terminal access 
method (BTAM), queued terminal access method 
(QTAM), virtual terminal access method (VTAM), 
and conversational mode (optional). 

Recovery Processing 

Checkpoint entire partition; restart from 
checkpoint limited to batch jobs only. Sequential 
and direct access devices repositioned but not 
I/O stream or unit record devices. 

Diagnostic Error Processing 

Hardware and program errors recognized and 
serviced; hardware error trace routines and hard¬ 
ware validity test supplied. 

Processing Support 

Timing Services: real-time clock. 

Testing and Debugging: postmortem and snap¬ 
shot dumps: no program debugging aids. 

Logging and Accounting 

Standard accounting data; no accounting 
routines provided; hardware error statistics kept. 

File Management 

Standard, user-defined, and nonstandard labels 
accepted; no file or volume system indexes 
permitted. 

File Structure 

Sequential and indexed. 

File Storage Allocation 

Auxiliary storage size and density defined by 
user. 

File Location 

User-defined file name and specific data set 
extents (direct access) and/or device address 
(magnetic tape, unit record, and so forth); hier¬ 
archical structures permitted. 

File Access Methods 

Sequential, indexed sequential, virtual stor¬ 
age access, and direct. 


Job Control Language 

Verb oriented. The statements describe each 
job step to be executed. The allowable options 
and specific identifications are described in the 
operation portion of the statement rather than as 
parameters within the statement (as in OS/360). 

Among the frequently used statements within 
the DOS JCL are those for identifying a job to the 
system, binding a symbolic name to a physical 
I/O device, providing a date for the job being 
executed, initiating execution of a task (job step), 
establishing program options, printing an I/O 
assignment list, providing volume and file label 
information, indicating limits of a direct access 
file, and identifying and locating checkpoint 
records for starting or restarting a job. 

Sorting and Merging 

A sort/merge program enables the user to 
sort single or multiple files, residing on tape or 
disc, into a user-specified order or to merge 
equally ordered files, residing on tape and/or 
disc, into one ordered file. The DOS/VS sort/ 
merge program product provides a number of 
additional functions. These include: 

• Security of information through an option 
to erase work files. 

• Flexibility through a facility to assign any 
programmer logical unit names for data or 
work files and to route sort messages to 
either the console or printer. 

• Serviceability through an option to obtain 
a storage dump after a critical message. 

• Low design point of 10K bytes real for all 
types of work devices. 

DESCRIPTION AND EVALUATION 

The enhancements offered to DOS by way of 
DOS/VS go a long way — but not all the way — 
toward solving the problems of its System/360 
counterpart. The enhancements include the vir¬ 
tual storage capability; five partitions as opposed 
to three; variable priority partitions; a spooling 
facility; cataloging of job control cards; and a 
relocatable loader. 

Of these enhancements, the spooling facility, 
relocatable loader, variable priority partitions, 
and cataloging of job control cards should have 
the most immediate impact on DOS users. The 
virtual memory and two additional partitions (one 
usable, since the spooling program resides in 
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the other) are powerful enhancements, but in 
most cases will have a greater future impact. 

The spooler feature is of particular note, for 
it at last permits DOS to perform multiprogram¬ 
ming with a degree of efficiency. It’s somewhat 
disappointing, however, that IBM chose to use 
Power as its spooler instead of developing a new 
spooling facility, since Power does not permit 
processing and output to proceed concurrently. 

Another shortcoming of DOS that is carried 
over to DOS/VS is the absence of an automatic 
volume sensing capability. Consequently, jobs 
will still have to wait for their assigned devices 
to become free, while idle devices remain idle. 

The relocatable loader and variable priority 
partitions will prove to be extremely valuable. 
With the relocatable loader, jobs stored in the 
core image library can be loaded and executed 
in any storage location. The variable priority 
partitions allow the user to designate partition 
priorities at SYSGEN and change them as re¬ 
quired. Consequently, high-priority jobs needn’t 
wait for a high-priority partition to become free 
or, worse yet, interrupt running jobs. The user 
may designate any partition as having the highest 
priority, to meet immediate processing demands. 

The Virtual Storage Access Method (VSAM), 
another welcome enhancement, is a functional 
replacement for the oft-maligned ISAM. Essen¬ 
tially, VSAM offers extended functions relative 
to ISAM, coupled with improved performance and 
a new data set organization. 

Let’s now examine the principal features of 
DOS/VS. 

Virtual Storage 

The virtual storage feature supports up to 
16 million bytes, divided into addressable 2K-byte 
pages. Likewise, the main storage partition is 
divided into 2K-byte regions (or frames, as IBM 
calls them) to receive these pages when entered. 

Reasons for employing paging were not too 
widely known when IBM announced VS, and 
neither were (or are) the real and potential draw¬ 
backs. The greatest benefits treated by the 
vendor are that it relieves the programmer from 
considering segmentation and to some extent core 
restrictions when laying out his program, and 
virtual memory also allows programs normally 
too large to fit, to get ”a shot at the CPU. ” 

Both statements are true. 

The programmer certainly can be a little lax 
in segmenting his program since he no longer has 


a space problem. If he does however, he could 
easily cause considerable throughput degradation. 
You see, when you’re dealing with segmented or 
paged programs the code you need during execu¬ 
tion may not be core resident when called. There¬ 
fore, the system must stop processing the pro¬ 
gram, go out to auxiliary storage and find the 
desired code, and transfer it to main memory. 

If the processor is preoccupied with this searching 
for codes, it enters a condition called ’’thrashing” 
and no productive work is being done. 

A solid solution to this problem is to have all 
code resident in main storage. But that defeats 
the purpose of virtual storage, doesn’t it? 

Another would be to determine which code is the 
most frequently called, place it on adjacent pages, 
increase the page size and keep it continuously 
main storage resident. This determining of the 
frequently called code is termed working set 
analysis, and is no easy task. 

Simply stated, a working set is the estimated 
number of pages which must be available in 
central storage to allow the job to run. Less 
pages waste space; the need for too many to fit 
available space results in thrashing. The working 
set can be determined by the machine or specified 
by the user. If the user specifies it, a technique 
called ’’lookahead” is employed. Here, the user 
specifies his working set and requires the machine 
to have available all the space required to load all 
pages at once. Since the machine is handling 
many jobs simultaneously, it must compare the 
core requirement with that available and ’’look 
ahead” during processing to determine when 
enough space will be available to enter the 
working set. 

If the machine does it, a technique called 
’’demand paging” is used. In this case, the ma¬ 
chine loads pages while retaining previously 
loaded pages, and pages are swapped in and out 
as demands change. 

Both techniques result in a fair amount of 
system overhead even if the working set is in¬ 
telligently specified. This could be improved 
substantially if the working sets were analyzed 
to determine which instructions are used most 
frequently by the program. The technique em¬ 
ployed for such analysis is sometimes referred 
to as ”80-20,” meaning that 20% of the code does 
80% of the work. Obviously, if this code were 
placed on pages that were continuously core 
resident, greater overall efficiency would result 
(no seeks or page swapping would be required) 
and the problem of thrashing considerably re¬ 
duced. To have the programmer determine this 
could present substantial problems. A better 
method would be to construct a compiler routine 
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to analyze and construct an optimal working set. 
No such routine, to our knowledge, exists. 

Another solution is program loop analysis. 
Program loop analysis is quite similar to working 
set analysis, eliminates the same problems, and 
results in similar efficiencies. Here the com¬ 
piler would break down the program into blocks 
of code and show their interaction. The intent 
would be to recognize loops and nested loops to 
allow simplification of the innermost loop. The 
compiler would then rearrange the code in a 
fashion to allow a loop to fit on one page (or more 
for a large loop) that would be core resident 
during loop execution. 

If virtual storage has all these problems, you 
may be asking yourself, "where does it fit?" 

That depends on the number and type of applica¬ 
tions you T re running, the size of your machine, 
and the attitude of your programming staff. 

If you run only a few batch applications on a 
small to medium machine, you may not need VS. 
However you may need the other benefits offered 
by the virtual machines. 

If you’re running a large number of core 
eaters, you can certainly benefit from VS, pro¬ 
vided your programs are laid out intelligently to 
head off thrashing. This places a further burden 
on your programmers, however, and we don’t 
have to tell you what that means. 

If your running a large mix of teleprocessing 
and local batch, VS can be most beneficial since 
you don’t have to dedicate large portions of main 
storage to serve infrequent applications (such as 
teleprocessing). 

Partition Support 

Increasing the number of partitions from 3 to 
5 would be significant, if it weren’t for the use of 
Power as the system spooler. Power is a large 
program (requiring about 18K bytes) and needs an 
entire partition to run. So, if you want spooling 
you’re down to 4 partitions. 

The user has the option of specifying from one 
to 5 partitions at SYSGEN time. Depending on 
other supervisor options, the addition of the 
fourth and fifth partitions adds a minimum of 
550 bytes per partition to a 3-partition resident 
supervisor. Multitasking support has been in¬ 
creased from 12 total tasks to 15 total (both main 
and subtasks) for the 5 partitions. 


Dispatching Priority 

The ability to specify the dispatching priority 
of a partition at SYSGEN and alter it at IPL time 
and during system operation adds considerable 
flexibility in job scheduling. Users are no longer 
bound by the old DOS scheme of servicing the 
foreground partitions first and the background 
last. Thus, high-priority jobs can be entered 
at any available partition — a nice enhancement. 

Relocatable Loader 

The relocatable loader is probably the most 
significant feature of DOS/VS, for it allows a 
program to be stored in the core image library 
in a format that enables it to be loaded and execu¬ 
ted in any storage location. Under old DOS, core 
image programs had to be executed in the same 
fixed storage location. 

In all, the relocatable loader adds a minimum 
of 1,100 bytes of additional storage to the resident 
supervisor. This figure will vary as hardware 
configurations change or options are added. Pro¬ 
grams stored in the relocatable format in the 
core image library will run with different super¬ 
visor sizes, with recompilation or additional 
linkage edit runs. 

Cataloging Control Cards 

Cataloging sets of job control cards on a direct 
access storage device simplifies system operation 
considerably. Now, at execution time, only one 
control card is needed to call a stored procedure 
and thus cause the execution of job steps specified 
in the procedure. 

Multiple Timer Facility 

The multiple timer facility can concurrently 
satisfy the timer request for all partitions. An 
option to the supervisor, it requires about 
1, 200 bytes of main storage. Users of IBM’s 
ITF and CICS will welcome the multiple timer, 
for it lets both operate concurrently on the same 
system without any special programming or 
operating procedures. 

Power 

The selection of Power, or more exactly 
Power’s characteristics, as the spooling vehicle 
should be welcomed with some reserve. As we 
pointed out, Power is a large program, requiring 
approximately 18K bytes. Further, it doesn’t 
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permit asynchronous execution of problem pro¬ 
gram and output as do some of the smaller, in¬ 
dependently developed DOS spooling packages 
(GRASP, DOS ASAP, SPOOLER, SPRINT, to 
name a few). Consequently, storage overhead 
is increased to hold the spooled data. However, 
Power does relieve DOS I/O from being limited 
by the speed of its unit record devices, and that 
should be good news for all. 

If the user elects not to use power, I/Os are 
handled by the old DOS-type input/output control 
system routines. 

In operation, Power reads the job streams 
(job control statements, programs, and data 
cards) for the individual partitions and stores 
these in input queues on disc. From there, the 
jobs are transferred by Power to the partitions 
and executed. Unit-record output (printer and 
punch, except the 2596 punch) of every job is 
stored on disc or tape before it is finally printed 
and/or punched. Job input as well as job output 
may be held in the Power queues for execution 
or printing/punching at a later time. 

Execution of Power may be controlled by the 
operator. He may start and stop input reading 
and output printing/punching independently of job 
execution. Whenever a card reader, a punch, 
or a printer becomes inoperative or fails, the 
system can continue processing with those jobs 
already in the input queues on disc and store the 
output of these jobs in the output queues. When 
the I/O unit becomes available again, reading, 
punching, or printing can continue. 

Power also offers a teleprocessing facility in 
the form of Remote Job Entry (RJE). With Power 
RJE, users may enter jobs for processing from 
remote terminals. RJE supports up to 5 IBM 
2770 or 2780 Data Transmission Terminals on 
the same number of leased or dial-up lines. 

Once a job has been entered into the input job 
queue, execution proceeds under DOS/VS super¬ 
vision. All data files required by the job are 
subject to DOS/VS specifications, just as if the 
job had been entered locally. 

RJE job output may be directed to the terminal 
from which the job was entered, to other termi¬ 
nals, or to the normal (local) output units of the 
system. It can be immediately transmitted to 
the specified unit-record device or be held in the 
Power queue for printing or punching on demand. 

Power is distributed as a set of macro instruc¬ 
tions and phases from which the user may assem¬ 
ble his own version according to his needs. One 


option is to generate a reduced version that per¬ 
forms printing and punching only (called a writer- 
only system). 

Through a system generation macro, the user 
may specify that input and output of Power queues 
be started automatically upon initiation of Power, 
rather than under operator control. 

Virtual Storage Access Method 

Users may choose from 4 types of access 
methods: sequential, indexed sequential, direct, 
and virtual. The first 3 are the same as offered 
with Release 26; the last is new. 

VSAM is a disc accessing method designed to 
be a functional replacement for ISAM. Essen¬ 
tially, VSAM offers extended functions relative 
to ISAM, coupled with improved performance and 
a new data set organization. Programs currently 
written to operate with ISAM can be converted 
via an ISAM interface routine and an ISAM-to- 
VSAM data set conversion facility to operate on 
VSAM data sets. No recompilation or link editing 
is needed. 

VSAM is mode compatible to ISAM by recog¬ 
nition of ISAM structure and automatic calling-in 
of interface routines. Hence, it is to the user's 
advantage to eliminate this performance-degrading 
activity by converting his files to VSAM. 

VSAM is the standard accessing method used 
with OS/VS1, OS/VS2, and DOS/VS. New VSAM 
capabilities unavailable in ISAM include: 

• Mass sequential insert. 

• Skip sequential. 

• Sequential and direct processing with one 
Open verb. 

• Multiple request processing (OS/VS only). 

• Data set sharing across partitions using 
track hold in DOS/VS, and within a region 
in OS/VS. 

• Device independence. 

• Portability of data sets between DOS/VS 
and OS/VS. 

• Variable length records, passwords, and 
catalog support for the DOS/VS user. 

Data portability between systems is possible 
because VSAM organization and access method 
are supported by DOS/VS and OS/VS. 
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VSAM operates with direct access devices and 
supports both direct and sequential processing by 
means of either index keys or relative byte ad¬ 
dresses. Both fixed and variable length records 
are supported. 

VSAM indexing capabilities include: nondense 
indexing; index key compression; index replica¬ 
tion (optional); high-level index in main storage 
(optional); low-level index with data (optional). 

Its cataloging capabilities comprise master and 
user catalogs for OS/VS and a master catalog 
for DOS/VS. 

The indexing method offered by VSAM employs 
nondense indexing and index key comparison. 
Nondense indexes do not point directly to indi¬ 
vidual records but instead point to larger units 
called control intervals. A control interval is a 
logical division of space in a data set utilizing 
VSAM organization. Since control intervals can 
contain a number of records, the overall effect 
is to shorten the index size and thereby decrease 
index search time and minimize index updating. 

Index key compression is based on the fact 
that portions of each index key are significant, 
while other portions are redundant. Compression 
removes the redundant characters and thus re¬ 
duces the index size and search time. 

Optional indexing features include: 

• Having the index records written repeatedly 
to minimize rotational delay; this feature 

is called ’’replicating the index. ” 

• Having the lowest level of the VSAM index 
adjacent to the data it controls. 

• Having the index on a different device from 
the data set. 

• Having the higher level of the index in main 
storage if sufficient buffer space is 
specified. 

Two significant improvements have been made 
to handle free space on disc: ISAM-like overflow 
chaining has been eliminated, and holes left by 
deleted records are automatically reclaimed. 

The latter is an apparent answer to the many 
complaints voiced by ISAM users about the wasted 
disc space that exists while awaiting the re¬ 
shuffling of records to fill the holes. In the past, 
many disgruntled users have turned to Comress’s 
AMIGOS for relief from ISAM’s inefficiencies. 

The VSAM method for eliminating overflow 
chaining is worth noting. The concept is called 
’’distributed free space” and works on a principle 


that requires certain partitions of VSAM control 
intervals and a specified number of extra control 
intervals to remain empty when the data set is 
initially created. Thus, inserts to the data set 
or changes to the length of existing records are 
accommodated by using the extra space. 

Virtual Telecommunications Access Method 

Three access methods are available to handle 
teleprocessing: the old BTAM and QTAM and the 
new virtual telecommunications access method 
(VTAM). 

VTAM is an integrated system control pro¬ 
gram for DOS/VS, OS/VSl and 2. It provides 
for direct transmission of data between applica¬ 
tion programs and terminals. Using the network 
control program (NCP) mode of the 3704/3705 
Communications Controller, it makes the lines 
and the communications controller transparent 
to the application program. 

VTAM also: 

• Provides dynamic sharing of network re¬ 
sources (including terminals, lines, and 
3704/3705s in NCP mode) among VTAM 
teleprocessing application programs. 

• Provides telecommunications support for 
multiple teleprocessing application pro¬ 
grams in a virtual-storage environment. 

• Enables programs using VTAM and TCAM, 
as well as those using TSO, to execute 
concurrently in the same system and share 
the same network. 

• Makes certain VTAM facilities (e. g. , net¬ 
work sharing) available to programs written 
for TCAM. 

• Provides a common base, with VSAM, for 
customer DB/DC systems. 

• Expands the basic telecommunication 
services available to the application 
programmer. 

• Aids in customizing and installing a tele¬ 
communications network. 


Program Interface. An application program 
requests VTAM’s services by first creating a 
control block that reflects the desired operation, 
and then issuing a macro instruction with a 
pointer to this control block as its principal 
operand. Macros are provided to create VTAM 
control blocks. 
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Using the macro language, the program can 
interface with VTAM connection services to 
make and break connections between itself and a 
terminal, receive notification if the operator 
breaks the connection, and switch connections to 
other application programs. 

An application program can be connected to, 
and communicate with, more than one terminal 
simultaneously. Using VTAM macro instructions, 
an application program can solicit input from a 
group of terminals via a single request. Using 
the macro language, the program can interface 
with VTAM data transfer facilities to request 
the actual transfer of data once a connection has 
been established between the application and a 
terminal. I/O requests may also be canceled 
and verified using these facilities. 

VTAM macro instructions include: SOLICIT, 
READ, WRITE, and RESET. Application pro¬ 
grams can also specify parameters in VTAM 
control blocks to alter requested I/O operations. 

SOLICIT causes VTAM to obtain data from 
terminals and store it in VTAM buffers. The 
data is moved to the application program’s work 
area when a READ is issued. 

READ causes the transfer of one block of data 
to the application program’s work area. 

WRITE causes a block of data to be written to 
a terminal. A READ automatically and immedi¬ 
ately follows a WRITE when the conversational 
option is used. 

RESET cancels outstanding I/O requests for 
the specified terminal or terminals. It may be 
issued at any time. 

Shared Networks . Under VTAM, network 
resources such as the 3704/3705 (in NCP mode), 
lines and terminals can be shared among VTAM 
and TCAM telecommunications application 
programs. 

Programs share terminals on a connection 
basis; that is, a terminal not already connected 
to an application may be available to other appli¬ 
cation programs using VTAM. However, once 
a terminal is connected to an application pro¬ 
gram, it cannot communicate with another pro¬ 
gram until the first program has released the 
terminal. 

The degree of terminal sharing depends upon 
limitations imposed by the customer installation. 
Terminal sharing can be limited by using VTAM 
options, including user authorization exits, to 


restrict the connection of specified terminals to 
only selected applications. 

Terminal sharing can also be affected by use 
of VTAM log-on/log-off facilities. Unless re¬ 
stricted, any available VTAM-controlled terminal 
can connect with any specified application pro— 
gram or with a TCAM MCP. Connection can be 
initiated by the terminal (via the log-on facilities 
of VTAM) or by the application program. 

Several application programs may communi¬ 
cate with different terminals on the same multi¬ 
point line. Also, terminals, whether on point- 
to-point or multipoint lines, may communicate 
with any of the teleprocessing application pro¬ 
grams using VTAM in the CPU. Application 
programs can use VTAM directly or indirectly 
via TCAM to obtain VTAM sharing capability for 
communications controllers, NCP-VSs, and 
lines. 

Diagnostics . Diagnostic aids include operating 
system and internal VTAM traces, operating sys¬ 
tem dumps (augmented by some VTAM formatting, 
on OS/VS only), the VTAM device diagnostics 
program TOLTEP (Teleprocessing On-Line Test 
Executive Program), software error recording 
(for OS/VS only), and hardware error recording. 

In addition to the diagnostic aids, the modular 
design of VTAM facilities debugging and main¬ 
tenance. Recovery procedures include operating 
system software error recovery programs (for 
OS/VS only) and hardware error recovery pro¬ 
grams, as well as IBM 3704/3705 recovery aids. 

TOLTEP is a component of VTAM and controls 
the selection, loading, and execution of telepro¬ 
cessing on-line terminal tests (OLTTs) for all 
control units and terminals in a VTAM network. 

It uses VTAM capabilities for line sharing, re¬ 
mote reporting, and remote test requests. 
TOLTEP performs control services, device 
accessing, and configuration-update functions 
for teleprocessing OLTTs of devices supported 
by VTAM. 

TOLTEP does not support the dedicated 
testing of a locally attached 3704/3705 Communi¬ 
cations Controller. Dedicated testing of the local 
3704/3705 is handled by OLTEP. 

Compatibility. Programs written in BAL, 
Cobol, or PL/1 that worked with TCAM will 
continue to work when the TCAM message control 
program (MCP) communicates through VTAM. 

The interface between TCAM application pro¬ 
grams and the MCP remains the same in the 
VTAM environment. 
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TCAM MCPs must be reassembled. For 
MCPs, a new parameter is required in the 
INTRO macro instructions if an MCP uses VTAM 
to support locally attached 3270 in a network that 
does not have a 3704/3705 in MCP mode. The 
new parameter is not required if an MCP supports 
the locally attained 3270s without going through 
VTAM. 

Except for TCAM, VTAM does not affect the 
function of other telecommunications access 
methods (BTAM or QTAM) or of I/O subsystems 
(Power, RES, JES2 or JES3). VTAM shares 
network resources only with programs using the 
telecommunications access methods VTAM and 
TCAM. Except in the case of PEP, network 
resources controlled by VTAM must be separate 
(though they can be within the same operating 
system) from those not controlled by VTAM. A 
single application program may use both BTAM 
and VTAM to support separate telecommunica¬ 
tions networks provided that all of the require¬ 
ments of both access methods are met. 

Terminal Support. VTAM supports locally 
attached IBM 3270 Information Display Stations 
as well as 3704/3705 Communications Controllers 
in NCP mode. It does not support the 2260, 

2715-1 (2790) or the 7770-3. 

Remote terminals are attached through a 3704 
or 3705, and operate in a switched or nonswitched 
network. These terminals include: 

• 1050 on a switched or nonswitched network. 

• 2740 Communication Terminal Model 1 on 
a switched or nonswitched network, with 
or without checking, and with or without 
station control or transmit control. 

• 2740 Communication Terminal Model 2 on 
a nonswitched network, with or without 
checking, and with or without the Buffer 
Receive feature. 

• 2741 Communication Terminal on a switched 
or nonswitched network. 

• Communicating Magnetic Card Selectric 
Typewriter on a switched network (2741 
terminal support only). 

• AT&T 83B3 Selective Calling Stations on a 
nonswitched network. 

• AT&T Model 33 or 35. 

• System/7 Processor Station in switched or 
nonswitched network. 


System Configuration. VTAM operates on the 
System/370 models 125, 135, 145, 155II and 158. 
VTAM requires a system with at least 96K bytes 
of real storage. 

Binary synchronous terminals support on 
switched or nonswitched networks are the IBM 
2770, 2780, 3735, 3740, 3780, System/3 CPU, 
System/370 as a remote station, 2972 Models 8 
and 11, and the 3270. 

DOS/VS Support Facilities 

IBM groups its support facilities for DOS/VS 
into a category called Reliability, Availability 
and Serviceability (RAS). RAS is composed of 
debugging aids; recovery management support 
recorder; environment recording, edit and print 
program; online test executive program; and 
reliability data extractor. 

The debugging aids provide the user with in¬ 
formation about his system at the time of a pro¬ 
gram, operator, or hardware error. 

The Recovery Management Support Recorder 
(RMSR), depending on the severity of the failure, 
enables the system to recover from an error 
condition caused by any of the following hardware 
failures: real storage errors, central processing 
unit instruction errors, input/output channel 
errors, control unit errors, and device errors. 

It also records hardware failures on the system 
recorder file (SYSREC) and prints messages on 
SYSLOG that keeps the operator informed about 
the condition of the system hardware. 

The Environment Recording, Edit and Print 
Program (EREP) allows the user to print the 
contents of the system recorder file, prefor¬ 
matted, on SYSLST. EREP has many options 
that provide the user and his IBM Customer 
Engineer with details about the state of his system 
hardware. 

The Online Test Executive Program (OLTEP), 
together with a set of device test programs, con¬ 
stitutes the online test system. Its functions 
include the diagnosing of I/O errors, the verifi¬ 
cation of I/O device repairs and engineering 
changes, and the checking of I/O devices. 

OLTEP is an optional program. If it is included 
in the system, it must be executed in real mode 
in the background partition. 

The Reliability Data Extractor (RDE) is an 
option that, if specified during system generation, 
enables the user and the customer engineer to 
record the reason for an IPL procedure as well 
as the number of IPL procedures carried out on 
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a system over any specified time period, for 
example, during an operator’s shift. RDE also 
enables a time stamp, END of DAY (EOD), to be 
recorded on SYSREC during system operation. 

Job Accounting 

The job accounting routines keep track of 
CPU usage as well as usage via an optional job 
accounting interface specified during SYSGEN. 
Such information as job name, date, partition 
in which the job is running are gathered, along 
with job start and stop times, CPU time used by 
the job and control program , and CPU idle time 


charged to the partition. Optionally, counts of 
the operation of I/O devices can also be gathered. 

At the end of each job step, a user written 
accounting program is loaded into the partition 
and billing is done; or accounting data is placed 
on auxiliary storage for further use. 


HEADQUARTERS 

International Business Machines Corporation 
113 Westchester Avenue 
White Plains NY 10604 
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UNIVAC 

1100 Series Exec 8 Operating Systems 


GENERAL 

Univac f s 1100 Series Exec 8 is a comprehen¬ 
sive group of routines designed to control all ac¬ 
tivities associated with job scheduling, hardware 
allocation, 1/O control and run supervision in a 
multiprogramming and multiprocessing environ¬ 
ment. The system permits concurrent batch de¬ 
mand (interactive), and real-time processing op¬ 
erations. Because the design of the executive 
system is highly modular, many parameters can 
be specified by the installation. 

In a multiprocessor configuration operating 
under control of the executive system, all pro¬ 
cessors are equivalent; that is, each processor 
can execute any required activity, including con¬ 
trol or supervisory routines. In certain cases, 
such as initiating input or output operations on a 
processor channel (as opposed to an I/O control¬ 
ler channel), the operation can be performed only 
by a particular processor, although any proces¬ 
sor can initiate the 1/O command. In a combined 
multiprocessor and multiprogramming environ¬ 
ment, the basic scheduling techniques are the 
same as those for the single-processor configu¬ 
ration, with each processor assigned the highest 
priority operation that can proceed when the pro¬ 
cessor completes the previously assigned tasks. 

Within any task, the executive provides the 
ability to code procedures that split a program 
into an arbitrary number of independent paths for 
processing on any of the system processors. The 
design of the system allows at least two proces¬ 
sors to work on a program simultaneously, with 
the resulting computation being optimally twice 
the speed of one processor. Increasing beyond 
two, however, does not provide a corresponding 
increase in speed, unless storage conflicts are 
prevented. 

All software is oriented toward making every 
activity of the 1100 Series operate under control 
of the executive system. These activities in¬ 
clude: Cobol, Fortran, and Algol compilations, 
as well as Assembler. With the standard batch¬ 
mode compilers, users at remote terminals 
generally submit complete tasks, with computer/ 
user communications occurring at the completion 
of each task. Typical tasks would be to complete, 
modify, or execute a program. In addition, a 
conversational-mode Fortran compiler is avail¬ 
able to permit remote users to compile and ex¬ 
ecute programs in statement-by-statement fash¬ 
ion. A standard interface is maintained for all 
language processors (translators), allowing ad¬ 
ditional language processors to be added to the 
system at a future date. 


The various language translators, such as the 
Fortran and Cobol compilers, maintain three to 
33 sequence counters when generating object 
coding. Separate areas are thus designated for 
data, for object coding, and for a common area. 
When allocating core storage for the execution of 
a program, the executive system attempts to 
assign each area to a different core memory 
module pair, to improve running efficiency by 
reducing cycle-stealing conflicts. Since the ac¬ 
tual disposition of core storage at allocation time 
may not permit this, the three program areas 
can be located in three, two, or even one mem¬ 
ory module pair. In addition, rearrangement, 
roll-out, or compacting of core storage can alter 
the relative locations of the individual program 
areas while a program is running — this is made 
possible by Univac ? s provision of program base 
register hardware. 

Operating Environment 

Exec 8 runs on any Univac 1100 Series config¬ 
uration that incorporates at least 786K words of 
FH-432 Magnetic Drum or equivalent storage. 
There are provisions in Exec 8 for handling an 
1100 Series configuration that includes at least 
131K words (36 bits each) of main memory, up 
to three central processors, and two I/O con¬ 
trollers. The minimum resident core storage 
requirement is 40K words. For certain installa¬ 
tions the residency requirements may be consid¬ 
erably higher, depending on how many types of 
peripheral devices are included in the configura¬ 
tion and whether there are routines to control 
real-time and demand processing. 

FUNCTIONAL CHARACTERISTICS 

Job Types 

Batch, real-time, interactive, and 
teleprocessing. 

Job Scheduling 

Job class priority, first in, first out (FIFO) 
intraqueue; start time and deadline limits as¬ 
signed by user. 

Resource Allocation 

Main Storage: dynamically assigned variable 
size regions. 

CPU Time: indefinite time slices. 

I/O Devices: dynamically assigned/reas¬ 
signed; devices can be dedicated to a job or 
shared. 
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Information Files: dynamically allocated; 
read/write only access; nonreusable, serially 
reusable, and reentrant routines and subroutines 
permitted. 

Program Structure and Loading 

Simple or user-specified variable size over¬ 
lays; all program modules compiled at base zero 
and mass storage addresses assigned by the op¬ 
erating system. 

I/O Control 

Device Types: disc, magnetic tape, drum, 
typewriters, video terminal, and unit record 
devices. 

Buffer Allocation: single buffer and buffer 
pool; each cataloged file assigned to a job must 
have an associated buffer pool. 

Remote Terminal Support: mixed line speeds 
and standard format. 

Recovery Processing 

Checkpoint all jobs except real time; restart 
from checkpoint; roll-out, roll-in all jobs except 
real-time; all files restored except cataloged 
mass storage files being updated; user specifies 
if dump is to be taken. 

Error Processing 

Hardware and program errors recognized and 
serviced; transient I/O errors cause automatic 
reinitiation of I/O operation. Hardware diagnos¬ 
tics permit tests for failed or failing components. 

Testing and Debugging 

Postmortem and snapshot dumps; routines 
available to record record data (messages, reg¬ 
ister and core dumps, and drum and tape dumps) 
in diagnostic file. 

Logging and Accounting 

Standard accounting data; no accounting rou¬ 
tines provided; hardware error statistics kept. 

File Management 

Indexed libraries of proc (like macros) code, 
source code, relocatable code, executable code; 
cataloging is dynamic; user and system labels 
permitted. 


File Structures 

Sequential and hierarchical structures per¬ 
mitted. 

File Storage Allocation 

Auxiliary storage size and density defined by 
user; storage assigned dynamically. 

File Location 

File name and password only using master 
catalog. 

File Access Methods 

Random, sequential, or indexed sequential 
(the latter works only with Cobol and assembly 
programs). 

Job Control Language 

Verb oriented . Functionally, IBM's JCL and 
Exec 8's executive control language (ECL) are the 
same in that they specify the job name, account¬ 
ing information, conditions for skipping steps 
within a job, priority, processor storage re¬ 
quirements, time required, I/O specifications, 
and so on. In short, everything that must be 
spelled out in JCL must likewise be spelled out 
in ECL. The difference is that while JCL com¬ 
prises three major, complex but extremely 
powerful statements, ECL has 31 relatively 
simple statements that permit the user to specify 
specialized functions; JCL requires the user to 
deal in abstract functions. 

The ECL statements are classified according 
to the specific functions they perform, namely: 

• Organizational — equivalent to the JOB 
JCL statement in OS JCL. 

• I/O Specification — equivalent to the DD 
JCL statement in OS JCL. 

• Processor Call — equivalent to the EXEC 
JCL statement in OS JCL. 

• Conditional Statement — equivalent to the 
JOB and EXEC statements in OS JCL. 

Sorting and Merging 

The sort/merge program consists of two sub¬ 
routines, which are not part of Exec 8 but oper¬ 
ate under its control. 

The sort subroutine performs a single-level 
sort and must be activated by a user program. 
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It can accept any volume of data in a particular 
sort run. The merge subroutine is capable of 
performing a single internal merge of 2 to 26 
presorted input files in accordance with specified 
keys. Like the sort subroutine, merge makes 
no assumptions as to the format and source of 
the original input files, thereby allowing com¬ 
plete flexibility in user formats and choice of 
original datafile storage media. 

Own-code can be used in both subroutines. If 
employed in merge, it must supply the address 
of a parameter table containing the key definitions 
for the desired merge. 

The main core storage required by sort/merge 
varies with the data block size* and whether only 
fast drum sorting is being done or whether fast 
drum and Fastrand mass storage are required. 
According to vendor-supplied literature, sorting 
5 million words requires 6,360,000 words of 
Fastrand, 636,000 words of FH-1732 drum, and 
22,000 words of main core. 

DESCRIPTION AND EVALUATION 

In overall sophistication and power, Exec 8 
ranks with OS/360 and Scope 3.3. In some areas, 
however, its capabilities are unequaled. 

Although Exec 8 can handle real-time and 
conversational processing, the principal orienta¬ 
tion of the operating system is towards maxi¬ 
mizing the throughput of batch jobs. Consequent¬ 
ly, no special "treatment" is given real-time and 
conversational jobs, nor are core regions re¬ 
served for them. 

Real-time processing is normally, but not 
exclusively, associated with data communica¬ 
tions or process control applications where delay 
in obtaining computer time could result in lost 
data or process malfunctions. Demand process¬ 
ing is typified by the need for "conversation" 
between the computer and the user; that is, the 
user specifies the execution of certain tasks 
depending on the results of previously initiated 
tasks. Batch processing is the normal execution 
of independent tasks (programs) or groups of 
tasks that are not highly time dependent. 

Input and output for the batch operations can 
take place either at the computer site or remotely 
via data communications links. The type of pro- 


* Larger block sizes do not improve the effi¬ 
ciency of the sort, but total system efficiency 
should improve because the number of ac¬ 
cesses to a device is reduced. 


cessing to be performed is indicated in the con¬ 
trol statements initiating a run. Time and facil¬ 
ity divisions between demand programs and batch 
programs are governed by a parameter specified 
by the installation. This parameter essentially 
designates the minimum proportion of processor 
time that will be devoted to batch processing 
whenever there are more requests for batch and 
demand processing than the computer can satisfy. 

Programs having demand status can utilize 
only the remainder of the processor time, even 
if infrequently referenced demand programs must 
be moved to mass storage areas between calls 
for them. Demand programs can utilize more 
than the specified amount of time if there are 
insufficient batch activities to fully use the time 
allocated to batch processing. This arrangement 
prevents demand programs from monopolizing 
the computer at the expense of batch programs; 
it allows the installation management to govern 
the processing ratio between batch and demand 
activities. 

Job Scheduling 

Three modules of the executive system are 
concerned with scheduling: the coarse scheduler, 
the dynamic allocator, and the dispatcher. 

The coarse scheduler interprets information 
from control statements taken from the "control 
stream." These statements can be entered from 
a card reader or other system component. The 
control information is used to queue jobs accord¬ 
ing to priorities specified by the system. 

The dynamic allocator accepts the highest- 
priority tasks from the queues maintained by the 
coarse scheduler and allocates the core storage. 

Separate dispatching queues are maintained 
for batch jobs and demand jobs. For each job 
initiated, the scheduler prepares a program con¬ 
trol table containing certain fixed information 
such as run ID, estimated run time, and files 
assigned. This table also includes variable in¬ 
formation such as the current facilities assigned 
and the core requirements of a particular job 
task being executed. The control table is main¬ 
tained by the dynamic allocation during task 
execution, and returned to scheduler control 
when the task terminates. 

The processing selection criteria employed 
by the coarse scheduler as far as batch jobs are 
concerned is based on the job T s priority, the 
availability of system resources, and an execu¬ 
tion start/deadline assigned by the user. If all 
factors are equal, jobs are selected from their 
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respective queues on a first in, first out basis. 
The operator, however, can change a job’s 
priority, start time, and deadline time and can 
selectively hold job scheduling or completely 
remove a job from a queue. 

A job’s priority is assigned by the system 
according the job category but can be changed 
by the operator prior to initiation. In the over¬ 
all priority scheme, executive and I/O are 
highest; real-time is next highest; and demand 
batch is lowest. 

Before a job is selected, the system checks 
a facilities inventory table to ensure that suffi¬ 
cient resources are available to let the job run 
to completion. If so, the job is scheduled; 
otherwise it remains in its queue, and the next 
job in that queue is examined. The procedure 
continues until all jobs in all queues have had an 
opportunity for selection. It should be noted, 
however, that all higher-priority jobs must be 
initiated before lower-priority jobs are selected. 

Since Exec 8 does not schedule a job unless 
sufficient system resources are available to 
allow it to run to completion, some minor sched¬ 
uling delays can occur. Processing jobs, how¬ 
ever, are not suspended — as is the case with 
OS/360 — to await needed resources. 

In the course of allocating time and space, 
the dynamic allocator maintains a set of queues 
and tables reflecting the state of all available 
tasks. These tasks include not only those in 
process, but also those not yet loaded and those 
temporarily suspended and held on mass storage. 

The dynamic allocator prepares a switch list, 
which is used by the dispatcher to give control 
to core-resident programs and to switch control 
among them as various events and contingencies 
arise. The dynamic allocator also periodically 
adjusts the switching level of programs or 
classes of programs to force the CPU time to 
b,^ used to comply with deadlines, priorities, 
interaction rates, and so forth. 

The start time/deadline feature is rather 
unique in that it ensures critical batch jobs won’t 
be buried in or by the high-priority job stream. 
The start time is specified, indicating when a 
job should be considered for execution. The 
deadline parameter specifies the time of day or 
an elapsed time from the point when a job is 
submitted until it must be completed. If the 
deadline cannot be met under normal scheduling, 
the system assigns the job the highest priority in 
the mix and, if necessary, rolls out processing 
jobs to provide the core required. The latter 
action, obviously, will degrade system operation 


as far as multiprogramming and system over¬ 
head are concerned. 

Demand processing deals with conversational 
jobs; as they appear they are initiated immediate¬ 
ly. Demand jobs, too, have assigned priorities. 
In addition to scheduling these are employed in 
overload situations to resolve conflicts in gain¬ 
ing external facility assignments and to give 
certain privileges in CPU assignment. 

Multiple demand jobs are queued within the 
demand group according to the relative job activ¬ 
ity rates. Processing time is allocated to de¬ 
mand programs sequentially, based on the de¬ 
mand switch list prepared by the dynamic allo¬ 
cator. A demand program maintains control for 
a predetermined length of time; then control is 
given either to a higher-priority activity (which 
can be another demand program) or to the next 
demand program in the list. 

Initially, all demand programs are given the 
same amount of execution time and are executed 
with the same frequency. The dynamic allocator 
monitors the progress of each demand program 
and alters the demand switch list on the basis 
of the frequency of interaction between the com¬ 
puter system and the remote user. If no user 
action occurs after one burst of execution, the 
amount of time (time slice) per execution phase 
is increased for that program and its position 
in the switched list is depressed. (The likelihood 
is that its frequency will be decreased.) Thus, 
the executive system attempts to optimize the 
computer’s usage by remote users in the demand 
mode. 

Real-time programs are submitted like batch 
jobs. Once initiated, however, the programs re¬ 
main core resident at all times even though they 
may be dormant while awaiting selected external 
interrupts. 

Multiple real-time jobs are queued within the 
real-time group on the basis of assigned job pri¬ 
orities. Programs in this class are allocated 
processing time and facilities up to the full 
capacity of the computer to ensure against lost 
data or a malfunction from a delayed response 
by the computer. 

Resource Allocation 

System facilities (resources), including I/O 
devices, channels, core and mass storage, are 
dynamically allocated to meet job requirements. 

In meting out resources, the system maintains 
and continually updates inventory tables that 
reflect the resources available for assignment 
as well as those currently assigned. 
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The method employed for allocating main core 
appears to be extremely efficient, in that a mini¬ 
mal amount of core checkerboarding will occur. 
Under the allocation scheme only enough core is 
allocated to meet a task’s immediate need, and 
base limit registers are set; as requirements 
change, the system dynamically assigns and 
releases core. This scheme is in sharp contrast 
to normal overlayable program segmentation 
(where enough core must be reserved to hold the 
largest segment) and fixed size memory 
partitions. 

Mass storage is treated much the same as 
core storage, in that space can be dynamically 
requested and released by the user. 

All user files must be assigned prior to ref¬ 
erence by I/O statements. Such assignments 
can be made via a control statement, via a 
supervisory request from within a user program, 
or via a supervisory request from within the 
executive system. 

Another notable feature — again aimed at in¬ 
creasing overall system efficiency — is the way 
I/O devices are handled. Simply, programs 
can dynamically assign and free devices as 
needed, as opposed to reserving files and/or 
facilities from the beginning of the job until com¬ 
pletion. Generally statements that assign and 
free I/O devices can be placed anywhere within 
the control stream, although they can be released 
by the user during the course of the run. Mag¬ 
netic tape units can be assigned to a particular 
channel or to a specific unit. When only the 
channel is selected, the supervisor chooses an 
available unit on the channel. 

Also available is an option for magnetic tape 
devices, which will release a file while reserving 
the physical facility. The facility, however, is 
placed in a pool for the job and is available for 
reassignment at any point within the job. It is 
not returned to the common pool (available to 
all jobs) until it is completely released or until 
the job terminates. 

The assignment of mass storage files can be 
on an exclusive or shared use basis. If a job re¬ 
quests exclusive use, it must wait until all other 
jobs have released the file. Conversely, if the 
file is assigned exclusively, all other jobs re¬ 
quiring the file must wait for its release. 

Exec 8 employs reentrant and serially reen¬ 
trant routines as the subroutine organization. 

Both types reside in and are called from a sys¬ 
tem library, as opposed to being incorporated as 
a part of the executing program during the binding 


process. When a reentrant routine is called, it 
is loaded into core and marked unavailable for 
swapping until all calling routines relinquish con¬ 
trol. The serially reentrant routines are called 
as needed and assigned to the exclusive use of 
the calling task. 

A special instruction called TEST AND SET 
allows a core-resident data base to be used by a 
number of different executing tasks or jobs. It 
also provides a means for controlling access to 
the data base, thus affording temporary protec¬ 
tion against data access while the common data is 
being modified. 

Program Loading 

Programs are constructed as relocatable 
modules, which are loaded dynamically by the 
dynamic allocator. Unlike the overlayable pro¬ 
gram structure, the dynamic technique does not 
require the core area size to be prespecified, 
nor does the module replace or overlay an exist¬ 
ing program segment. It does lead to core frag¬ 
mentation (checkerboarding), however, for 
dynamically loaded programs do not always ter¬ 
minate at the same time. This results in core 
holes that are too large for some programs to 
use efficiently or too small for some to fit at all. 

Input/Output Control 

In some configurations (particularly ones 
utilizing I/O controllers), redundant data paths 
to the peripheral subsystems are implemented 
via multiple processor adapters, so a given 
peripheral subsystem can be addressed either 
through a processor channel or through an I/O 
controller channel. This structure provides 
backup in case of component malfunction and per¬ 
mits uninterrupted operation during maintenance. 
Preferred paths are assigned by the installation, 
while the executive system provides the capability 
to switch to redundant paths when the preferred 
path is unavailable. 

I/O Scheduling . I/O operations are controlled 
by a central I/O routine which accepts and queues 
requests and interrupts, and passes control to 
the I/O device handler. Sixteen I/O channels are 
available and can operate as partial dual chan¬ 
nels, full dual channels, and dual computer 
channels. 

A program references I/O control by means 
of executive requests which, in turn, enter the 
I/O handler controlling the device referenced. 

The handler examines the request and queues it 
against the channel. When the channel is freed, 
the entry is moved from the channel queue and 
the handler entered at the appropriate point. 
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The executive system classifies an I/O re¬ 
quest in accordance with the assigned category, 
viz., executive, real-time, and demand/batch. 
All requests in a higher category must be ser¬ 
viced before any lower-priority request is con¬ 
sidered. Lookahead techniques are used within 
each category in an effort to reduce the execution 
time for I/O requests. Since lookahead usually 
causes completion of requests in a sequence 
different from the order of submission, the user 
must supply his own code if protection is desired 
and/or if the user is concerned with the execu¬ 
tion sequence. 

Data Transfer 

Like most operating systems. Exec 8 spools 
data from slow unit record devices to mass stor¬ 
age (i.e., unitized channel storage, discs, or 
drums). When called, the data is loaded into 
core buffers. 

For magnetic tape mass storage, and com¬ 
munication devices, the system provides both 
single-buffer and buffer pool capabilities. Sep¬ 
arate buffer pools are maintained for data files 
and communication devices. For each cataloged 
file assigned to a job, there must be an associ¬ 
ated buffer pool. A buffer pool can be assigned 
to one particular file or to many files. The size 
of each buffer, however, must be equal to the 
maximum block size specified for the file plus 
3 extra words for control purposes. If the com¬ 
munication handler is employed, an associated 
buffer pool can be established in any portion of 
core the user sets aside as an I/O area. 

The data handling routines process files at 
the item, record, or block levels, with general 
disregard for the physical characteristics of the 
I/O device assigned. File access can be either 
random, sequential, or indexed sequential. The 
latter works only with Cobol and assembly 
programs. 

Exec 8 data handling techniques are quite so¬ 
phisticated, encompassing many of the functions 
normally associated with independent data man¬ 
agement systems. Each file is defined by file 
format and item definition; an item control table 
enables users to access any item of a record on 
request. 

A teleprocessing subsystem is available with¬ 
in the resident executive to handle all communi¬ 
cations processing for a large number of inde¬ 
pendent terminals. The communications multi¬ 
plexer handler presents a common focal point 
between the multitude of available remote ter¬ 
minal devices and the programs to be executed. 


The diversity of available hardware dictates a 
general routine on which the variances of each 
application can be built. 

The communications handler supports 2 
other modes of operation. The first level con¬ 
sists of a buffer-handling mode in which the 
handler supervises transmitting and receiving 
messages on a buffer-by-buffer basis, with no 
assumption concerning the content of each buffer. 
The second level of support assumes a system- 
defined format on devices capable of acknowledg¬ 
ing transmission. 

An extensive set of device manipulation func¬ 
tions is available through an independent file 
utility processor. This processor is called 
whenever a control statement referencing a file 
is recognized. The file utility processor per¬ 
mits file copying and positioning. 

File Handling 

A file control supervisor is used to control 
the creation and maintenance of all program and 
data files. It also maintains an up-to-date 
master directory of files cataloged and the status 
of mass storage availability, as well as individ¬ 
ual file directories. 

For each file declared, other than temporary 
files, an entry containing the identification and 
characteristics of the file is maintained by the 
system in the master directory. A typical entry 
shows: external name of the file, including 
qualifier; file creation date; retention period; 
activity of file, including date of last reference; 
passwords; device type, parity, density, etc.; 
numbers of granules assigned; and link to indi¬ 
vidual file directory. 

For a mass storage file, the master direc¬ 
tory entry points to the location of an individual 
file directory and is used to direct the retrieval 
and storage of data specified by the user. In 
effect, each file directory contains enough in¬ 
formation to allow the system to know exactly 
where each file block is stored. For magnetic 
tape files, the master directory entry identifies 
the reels of the file and lists the recording char¬ 
acteristics of the file and its password. 

Magnetic tape label checking facilities are 
offered as an installation option. Each label is 
checked against master directory entries every 
time the tape is mounted. A provision is also 
made for writing header labels. No trailer label 
read capability is provided; consequently, tapes 
cannot be read backwards. 
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Support Utilities 

Overall, the system support utilities pro¬ 
vided are extremely good — consisting of the job 
accounting and equipment usage routines de¬ 
scribed previously; a capability to monitor a job 
or job setup at various points during its pro¬ 
gramming cycle; and a hardware confidence test. 
The latter is particularly notable, for it permits 
the user to test for faulty error components and 
take action before errors occur. 

No testing facility is provided for determining 
data bottlenecks by measuring data flow either 
over channels or through registers. 

Under the logging and accounting routines, an 
extensive system is maintained to collect infor¬ 
mation pertaining to each job and program. The 
information log is later used for accounting and 
post-execution processing. The basic types of 
information entered in the log are facility usage, 
job termination data, and the logging entries 
made by log control cards or executive requests. 
A master log is also maintained showing the 
occurrence of I/O errors; errors are counted 
for mass storage and magnetic tape devices. 

Such record data is invaluable in determining if 
components are going "soft, " thus allowing cor¬ 
rective measures before "hard" failures occur. 

A set of allowable account numbers is incor¬ 
porated into the system at generation time. A 
job is not accepted if the account number is not 
known to the system, and the operator is notified. 
The operator may abort the job or accept the 
new account number. If he accepts the new num¬ 
ber, it may be added to the permanent set. 


At each run termination a summary accounting 
routine is activated and the following information 
is provided: project identity, account number, 
total run time, pages of printing applicable to the 
job, number of cards read in and punched out, 
time and date of job initiation and any communi¬ 
cation with the operator console. The accounting 
routine reads and updates all totals maintained. 

The accounting file is permanently assigned 
as a mass storage file. Continuing totals are 
kept until cleared by a billing routine or replaced 
during system loading. A procedure for execut¬ 
ing the billing routine must be established by 
the user. 

Another special accounting file is also main¬ 
tained by the executive system to provide limited 
summary accounting information. The informa¬ 
tion is accumulated by account number at the 
time of job completion. The summary accumu¬ 
lates information on the following items: run 
time, time and date of first entry to the account 
number, time and date of last entry to the ac¬ 
count number, number of pages printed, number 
of cards read, number of cards punched, and 
elapsed time an I/O facility has been assigned to 
the account. The summary accounting file is 
first constructed during system generation and 
includes the scheduling limitations for each 
account. 

HEADQUARTERS 

Sperry Rand Corporation 
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Operating System/7 (OS/7) 


GENERAL 

OS/7 is a comprehensive set of language 
translators and service programs designed to 
furnish medium and large scale Series 90 users 
with multiprogramming and telecommunications 
control. OS/7 is highly modular and can be gen¬ 
erated with widely varing configurations, depend¬ 
ing upon the control functions required. The 
system can be configured to run up to 14 jobs 
concurrently in variable size main memory 
regions. 

The processing programs provided and 
controlled by the system include routines for 
telecommunications processing, language trans¬ 
lators, service programs, and the user’s own 
problem programs. User programs can be writ¬ 
ten in RPG, Cobol, Fortran, and macro 
assembler. 

Program structures permitted are simple 
structure or planned overlays. The user speci¬ 
fies overlay sizes and all programs are com¬ 
piled to relative zero using a base/displacement 
format. Hardware registers are used in the 
actual loading or subsequent movement of a job 
to provide larger blocks of free memory. The 
starting location of a program is loaded into a 
relocation register and is then added by hardware 
to every address generated in the program. A 
program can then be dynamically moved in mem¬ 
ory and the only address that must be changed is 
the relocation address. 

In addition to simple and overlay program 
structures, OS/7 also supports multitasking. 
Multitasking allows a program to create a sub¬ 
task that operates asynchronously with its parent 
task. Facilities are provided that allow the par¬ 
ent task to start or stop a subtask, to pass in¬ 
formation to or collect information from the sub¬ 
task, and to take action upon subtask completion 
or error condition. 


The program development stages of OS/7 are 
shown in Figure 1. 

Object modules produced by a compiler or as¬ 
sembler can be link edited immediately, or they 
can be stored in an object module library and 
link edited later. The output of the linkage editor 
consists of one or more program phases which 
may be stored in a load module and subsequently 
transferred to the system loader. 

The linkage editor can construct a single exe¬ 
cutable load module from several object modules. 
Thus a change to one object module only requires 
that module be reassembled. A benefit of this 
type of linkage is that modules consisting of pro¬ 
grams written in different languages can be com¬ 
bined into one executable program. The linkage 
editor can also produce multiphase load modules 
with the necessary information and system sub¬ 
routines needed to load the phases automatically. 

In addition to the linking function, the linkage 
editor also: searches the system and user li¬ 
braries and inserts designated programs; deletes 
and rearranges control sections of an object 
module as directed; produces an overlay struc¬ 
ture to be used by the supervisor during loading; 
and reserves common storage requests generated 
by the language processors. 

OS/7 uses a spooling technique consisting of 
a set of routines that buffer data files from 
low speed input and output devices to disc. Out¬ 
put is spooled to tape for off-line printing or disc 
for on-line printing or display. Forms control 
for printer buffers and recovery at line or page 
increments are provided. It is also possible to 
produce multiple copies of a buffered output file. 

Data Communications 

The data communications facility of OS/7 is 
provided by means of a Data Communications 
Subsystem connected to the multiplexor channel 



Figure 1. OS/7: Program Development Stages 
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or to the communications intelligence channel. 
Similar facilities are provided by both systems 
(that is, physical I/O control system, message 
control, and message processing). 

Macros are provided to define the line groups, 
networks, and terminals. These macros are the 
means by which buffer requirements, line and 
terminal characteristics, queues, and special 
line handling requirements are defined by the 
user. 

The message control program is the major 
component of the communications control pro¬ 
gram and operates as a separate job with prime 
priority on the supervisor switch list. The 
message control program handles message flow, 
line control, message acknowledgment, buffering, 
main and direct access storage queuing, error 
handling, message translation, polling, and op¬ 
erator communications. 

Optional features of the message control pro¬ 
gram permit users to audit error conditions, 
maintain error counts and header summaries, 
and provide traffic analysis information. Also 
supported are audit trails, data integrity, and 
various editing functions, plus multiple destina¬ 
tion routing, broadcast messages, rerouting, 
automatic store and forward, and message 
switching. 

Messages are queued on disc or in main stor¬ 
age by priority and are transferred to their des¬ 
tinations also by priority. Urgent messages 
temporarily override other message priorities 
during transmission. 

The data communications program is 20-50K 
bytes long and handles ICAM (a cross between 
BTAM and QTAM). Terminal devices handled 
by the system are: Teletype Models 28, 32, 33, 
35, and 37; Uniscope 100 Display Terminal; 
Univac DCT 500, 1000, and 2000; Univac 9200/ 
9300/9400 and 1004/1005; and IBM 2780 binary 
synchronous communications. 

Remote Job Entry. Communications input 
readers and output writers provide spool-in and 
spool-out of remote entry jobs independent of 
other system functions. Priority queues exist 
within the operating system for scheduling RJE 
jobs, and job and system status are available for 
operator inquiry. The remote job control lan¬ 
guage is identical to the standard on-site JCL 
with the exception that some additional informa¬ 
tion, which uniquely identifies the remote station, 
is required. An option is provided which allows 
outs of remotely executed jobs to be delivered to 
central site peripherals rather than returned to 
the remote station. 


Emulators 

Emulators for most of the IBM 360 series, 

IBM 1400, Univac Series 70 (TDOS and DOS), 
and Univac 301 and 501 are an integrated part of 
the operating environment and allow concurrent 
operation with the OS/7. Stand-alone versions 
for the System 360 and Series 70 are offered as 
well. Two processor emulator features are 
available to allow one or two separate emulators, 
depending on the users requirements, to be run. 

Operating Environment 

OS/7 requires at least 62.7K bytes of main 
storage, however, because OS/7 provides write 
protection on a 4K boundary, the minimum sys¬ 
tem actually uses 64K. Instead of being resident, 
features that are only used occasionally, such as 
Task Management, Error Recovery, or File Open 
and Close, are brought into the system as over¬ 
lays into a transient area (each transient area 
is 2.3K bytes). Since these routines can compete 
for the same transient areas, up to eight addi¬ 
tional areas can be allocated to improve system 
performance. Although this provides flexibility 
it also requires the user to determine his own 
balance of main storage usage versus system 
performance. 

In addition to its main memory require¬ 
ments, OS/7 also requires two disc drives, an 
operator’s console, one card reader and one 
printer. 

FUNCTIONAL CHARACTERISTICS 

Job Types 

Batch and teleprocessing. 

Job Scheduling 

Numeric priority only; jobs are queued by 
priority and selected on a first-in, first-fit basis. 

Resource Allocation 

Main Storage: variable size regions. 

CPU Time: indefinite time slice. 

I/O Devices: dynamically assigned and 

reassigned. 

Information Files: dynamically assigned; 

shareable and nonshareable programs and 

subroutines permitted. 

Program Structure and Loading 

Simple structure or planned overlays. User 
specifies overlay sizes; all programs compiled 
at base zero and disc addresses are assigned by 
the operating system. 
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I/O Control 

Device Types: disc, magnetic tapes, unit 
record devices, and video display. 

Scheduling Performed: physical device only; 
input spooled to disc; output spooled to tape or 
disc. 

Buffer Allocation: single or double buffering 
assigned dynamically from a common pool. 

Remote Terminal Support: standard terminal 
speed and format. 

Recovery Processing 

Checkpoint/restart all jobs or job steps; roll- 
in/roll-out all jobs; serial and direct access de¬ 
vices automatically repositioned. 

Diagnostic Error Processing 

Hardware and program errors recognized and 
serviced; minor errors retried before termina¬ 
tion. Failed components marked inoperative but 
system not automatically reconfigured. On-line 
diagnostics tests for failing components. 

Processing Support 

Timing Services: interval and real-time. 
Testing and Debugging: postmortem and snap¬ 
shot dumps. 

Logging and Accounting 

Standard accounting data; no accounting rou¬ 
tines provided. Hardware error statistics kept 
to show components are going soft. 

File Management 

Indexed libraries of macro code, relocatable 
code, and executable code. 

File Structures 

Sequential, indexed and direct (standard); 
hierarchical, ring, tree, list, and inverted with 
DMS/90 (optional). 

File Storage Allocation 

Auxiliary storage size defined by user; stor¬ 
age assigned by user. 

File Location 

File name only using master catalog; hierar¬ 
chical structure permitted with DMS/90 (optional). 


File Access Methods 

Sequential, indexed sequential, direct, and 
system integrated access method (SIAM). 

Job Control Language 

Verb oriented . The statements describe each 
job step to be executed. The allowable options 
and specific identifications are described in the 
operation portion of the statement, rather than 
as parameters within the statement. 

Among the frequently used statements are 
those for identifying a job to the system, binding 
a symbolic name to a physical I/O device, pro¬ 
viding a date for the job being executed, initiating 
execution of a task (job step), establishing pro¬ 
gram options, printing an I/O assignment list, 
providing volume and file label information, in¬ 
dicating limits of a direct access file, and iden¬ 
tifying and locating checkpoint records for start¬ 
ing or restarting a job. 


Sorting and Merging 

The sort/merge utility is a multiphase, mul¬ 
timodule program that provides an interface that 
permits disc only, tape only, or tape/disc sorts 
of large or small volume files. Its multicycle 
capability allows an unlimited volume of data to 
be sorted automatically or in separate phases. 
Fixed-length and variable-length records are 
acceptable. 

The system permits up to 255 key fields, and 
sorting can be on noncontiguous key fields in as¬ 
cending or descending order (or in any combina¬ 
tion). Tag sorting and merging of files of pre¬ 
viously sequenced records is also permitted. 

For a disc sort, the available storage must 
be large enough to contain the entire file plus 
sort control information of approximately 5 or 
10 percent. Up to eight standard disc file names 
may be assigned. 

A tape sort requires three tape units. Up to 
14 tape units can be assigned. A maximum of six 
tapes is used by the sort subroutine for string 
collating. This sort allows a user to execute a 
multicycle tape sort using the shared input and 
reserved output devices. 

The tape/disc sort requires disc storage 
equal to that needed to hold the data plus 10 per¬ 
cent, or three tape units (although more is ad¬ 
visable). The use of the disc and tape auxiliary 
storage in combination assumes a multicycle 
sort. 
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DESCRIPTION AND EVALUATION 

OS/7 is intended specifically for the Univac 
Series 90 (nee 9000) Models 60 and up. The 
Series 90 itself is marketed to offer IBM System/ 
360 and 370 medium scale system users operat¬ 
ing under DOS an opportunity to move up to more 
powerful hardware and a less restrictive operat¬ 
ing system without going to virtual storage. 

OS/7 is completely compatible with DOS Re¬ 
lease 26 and offers many capabilities not nor¬ 
mally available with the IBM product. For ex¬ 
ample, the Univac offering employs variable size 
main storage regions; allows multiprogramming 
of up to 14 concurrent jobs; offers a built-in 
spooler; and provides program relocatability. 

DOS employs fixed size main storage partitions; 
offers spooling as an option that requires its own 
processing partition; and has no program module 
relocatability feature. 

However, a more powerful and complex oper¬ 
ating system generally requires a more sophis¬ 
ticated and knowledgeable user to fully realize all 
its benefits. Such is the case with OS/7, espe¬ 
cially in light of the way it schedules and selects 
jobs for processing and allocates system re¬ 
sources (especially main memory). 

The following paragraphs highlights the more 
notable features OS/7, Release 1, with com¬ 
ments concerning its strengths and weaknesses. 
Release 1 is scheduled for delivery in January 
1974; Release 2 of OS/7 is scheduled for delivery 
one year later. 

Job Scheduling 

The job scheduling techniques employed by 
both releases will do a competent enough job pro¬ 
vided you carefully plan your job mix. Such fac¬ 
tors as main storage requirements, run times, 
and resource utilization must be carefully ana¬ 
lyzed and weighed, for resource conflicts could 
have a very detrimental effect on throughput. On 
the otherhand, if the user devotes a little time to 
constructing his job mix intelligently, he’ll be 
rewarded with both high throughput and very good 
resource utilization. 

Release 1 of OS/7 uses a straight numeric 
priority scheme. Here a user merely assigns a 
numeric priority consistent with the urgency of 
the job. In all, 99 priorities and queues are of¬ 
fered, with 1 being highest and 99 lowest. (The 
system assigns priorities in default.) A job’s 
position within its respective queue is determined 
on a first-in, first-queued basis. The servicing 
of jobs (that is, scheduling) is performed round- 
robin intraqueue and straight priority interqueue. 


Jobs for each of the 99 queues are selected for 
processing on a first-fit basis. Fit in this case 
means the main storage available is large enough 
to hold the programs root segment plus its larg¬ 
est overlay, and all required resources are avail¬ 
able. (See Resource Allocation .) In addition, 
OS/7 requires each job to have available all re¬ 
sources it will need to run to completion before 
the job is permitted to begin executing. If suffi¬ 
cient resources are unavailable, the job waits in 
the queue regardless of priority unless the oper¬ 
ator decides to abort running jobs in its favor. 

Once a job gains access to the machine, it 
runs to completion under a user assigned time 
slice. It cannot be automatically aborted by a 
higher priority job, as is the case with some op¬ 
erating systems. All aborting must be done by 
the operator. In our opinion, this is an excellent 
feature for it prohibits users from using and 
abusing high priority privileges to abort lower 
priority jobs just to meet a schedule. It also al¬ 
lows the operator to judge the wisdom of inter¬ 
rupting two or three jobs just to service the 
needs of one higher priority member. 

The drawback with this procedure, of course, 
is that the operator has one more task to do — 
and a critical one at that. An unsophisticated or 
novice operator could do some serious damage 
to throughput with this much power. This prob¬ 
lem unfortunately is compounded by the fact that 
OS/7 aborts running jobs, as opposed to using a 
roll-in/roll-out procedure to handle a process¬ 
ing interruption. 

The straight numeric scheme also favors high 
priority jobs over their lower priority brothers. 
Users know this too, and are tempted to assign 
unnecessarily high designators to jobs just to get 
them scheduled. The result is a backup of high 
priority jobs and the almost total exclusion of 
those who played it honest. 

One way to beat the numbers game is to in¬ 
stitute a job class-numeric assignment scheme, 
whereby a job class would carry one weight and 
the numeric designator another. The scheduler 
would then select jobs on a best mix basis to en¬ 
sure that all classes had a reasonable chance to 
get a shot at the CPU. A job class-numeric 
scheme is not possible under Release 1 of OS/7, 
but it could be done with Release 2. Until that 
release arrives however, youTl have to exercise 
strict control on the use of numeric designators 
to ensure a reasonable job mix. 

Resource Allocation 

System resources — internal storage, I/O de¬ 
vices, and information files — are automatically 
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assigned according to need. Assignments take 
place on a priority basis, with the system keep¬ 
ing track of all assignments. Likewise, the sys¬ 
tem frees resources upon task completion. As 
sufficient resources become available they are 
assigned to the highest ranking jobs. 

Internal storage is maintained in a common 
pool and assigned to programs as needed. The 
amount allocated is determined by the maximum 
amount of code which must be resident during 
program execution. 

Main Storage. Main storage is assigned in 
contiguous blocks, the base-limit addresses of 
which are determined by OS/7. Registers within 
the processor indicate the bases of the various 
areas during program execution. OS/7 accommo¬ 
dates programs organized into segments of vary¬ 
ing sizes, as opposed to fixed-size programs. 

Jobs are assigned core in accordance with 
their numeric ranking. The highest ranking job 
is entered first, with lesser ranking jobs follow¬ 
ing. Prior to assigning a job, the system com¬ 
pares its main storage requirements with the 
amount of contiguous main storage available. If 
the job fits an available area, it’s entered. 
Otherwise, all priorities being equal, the next 
ranking job is considered, and so on. 

When sufficient contiguous main storage is not 
available, the system checks the amount process¬ 
ing jobs assigned to determine if any is unused. 

If so, compaction is performed by reorganizing 
all processing jobs to fill vacant areas and then 
resetting the base-limit registers to reflect the 
new locations of these jobs. 

These methods of assigning main storage lead 
to checkerboarding, even when compaction is 
done. For example, suppose 18K bytes of con¬ 
tiguous storage exist and the highest ranking job 
needs 16K. That job is entered and 2K is wasted. 

Main Storage compaction won’t solve the prob¬ 
lem either, for two reasons: (1) the programs 
used must be in the form of root segments and 
overlayable segments, and (2) enough contiguous 
storage must be reserved to hold the root plus 
the largest overlayable segment combination — 
regardless of whether or not the overlay is resi¬ 
dent. When it is not, the storage is unused and 
the checkerboard occurs. 

Shared Files. OS/7 permits the sharing of 
direct access files through its physical IOCS 
facilities. The physical IOCS provides a lockout 
to prevent reading or writing a record while it is 
being updated. In addition, if the status of a file 
is to be changed dynamically from shared to non- 
shared while updating, this can be explicitly re¬ 


quested of the supervisor by requesting non- 
shared use of the file. 

Files generated and maintained by the system 
are protected by the supervisor. Only authorized 
data management users are allowed to write on a 
device which contains a volume on which pro¬ 
tected files are stored. 

Device Assignment . The user can specify 
whether a device is to be assigned for the dura¬ 
tion of the entire job or for only a job step. The 
user can also dynamically deallocate a device 
during job execution or can deallocate the device 
at termination of the job or job step. 

Devices of varying types can be collected into 
groups which are named by the user and the pro¬ 
per device relationship is established during de¬ 
vice allocation procedures. Thus by referencing 
group names instead of device types or logical 
unit numbers during execution, the user gains 
a considerable degree of device independence. 

Automatic Volume Recognition. Automatic 
volume recognition is an excellent feature for 
it allows the operator to mount labeled volumes 
on available units before receiving the request¬ 
ing message. The system recognizes the volumes 
by their labels and later assigns these pre¬ 
mounted volumes to the first job steps calling 
for them. The net result is that set-up time is 
reduced and overall throughput is increased. 

Data Management 

The data management facilities offered as far 
as file accessing techniques are concerned are 
the standard mix: sequential, indexed sequen¬ 
tial, and direct. OS/7, however, also offers an 
access called System Integrated Access Method 
(SIAM). SIAM centralizes and standardizes all 
I/O done by system routines. It is structured in 
much the same manner as other data manage¬ 
ment access methods and uses DTF tables, re¬ 
entrant modules, processing macro instructions, 
and overlay routines. It is a disc oriented 
method and offers device independence for the 
8411, 8414, 8424, and 8440 Disc Subsystems. 
Support is also provided for tapes with some de¬ 
gree of disc-type independence between tape and 
disc. 

SIAM supports a user oriented index struc¬ 
ture. Names in the index can be fixed or vari¬ 
able in length. Other features are fixed block 
size with writing and reading of multiple num¬ 
bers of blocks to reduce disc access, and vari¬ 
able length record support. SIAM files can be 
organized as sequential, sequential with subfiles, 
partitioned, and random by name. 
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Diagnostic and Trace Routines 

Overall the diagnostic and trace routines 
offered are fairly good. The system diagnostics, 
particularly the Design and Verification Rou¬ 
tine (DVR), on-line diagnostics, and prognostics 
routines, are well worth examining, however. 

DVR is a system integrity check. It can be 
run at any time and verifies that all system logic 
I/O channels and hardware components are func¬ 
tioning correctly. The on-line diagnostics checks 
if a device is malfunctioning, pinpoints the error, 
and offers suggestions on how to correct it. It 
also insulates the failed device from the rest of 
the system. 


Th& Prognostics routines measure the degree 
to which tape components are matching the de¬ 
gree of performance specified. This test will be 
available to disc components in the future. The 
Prognostics routines, however, cannot determine 
if main storage or components of main storage 
are about to fail. It does not automatically re¬ 
configure the system around failed components 
either. However, if one bank of main memory 
fails, that bank can be isolated and the remainder 
of the system reconfigured. 

HEADQUARTERS 

Sperry-Univac 
P. O. Box 500 
Blue Bell PA 19422 
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APPLIED DATA RESEARCH 

PiSort 2 


GENERAL 

PiSort is a generalized sort program for files 
with fixed length, blocked, or unblocked records. 
It is purported to operate in less time and with 
less working space than IBM’s sort 483. 

PiSort runs on any IBM System/360, 370 mod¬ 
el under DOS with 2OK bytes of core storage 
when using a 2311 for intermediate storage, or 
30K bytes of core when using a 2314. A version 
employing the 3330 (40K bytes) is scheduled for 
release in late 1973. PiSort is a single program 
with multiple overlays, written in BAL. 

The package can be leased for $100 a month 
or permanent licensed for $2,000. 

Introduced in 1970, PiSort is operational in 
approximately 125 installations. It has undergone 
2 major revisions with extensions added as de¬ 
mand warrants. 

DESCRIPTION 

Functionally compatible with IBM's sort 483, 
PiSort is cataloged into the core image library 
as an integral part of the sorting operation. It 
does not delete any IBM modules but renames 1. 
The IBM module remains, ensuring total backup. 
Complete control card compatibility exists be¬ 
tween sort 483 and PiSort. 

PiSort sorting algorithm handles fixed length, 
blocked, or unblocked records. 

When PiSort is called on to sort a file which 
does not meet its requirements (or uses any of 
several other unsupported features — see Evalua¬ 
tion ), control is passed automatically to sort 483 
to handle the operation. 

PiSort's processing efficiency is directly pro¬ 
portional to the amount of core storage available. 
It can theoretically sort a file approximately 20 
to 25% faster than sort 483, depending on the file 
contents. In many cases, the vendor claims, 
PiSort cuts disc work space in half. PiSort is 
frequently able to sort files too large for Sort to 
handle at 1 time (i. e. , files which sort 483 must 
divide into subfiles, sort, and then merge into 
the final file). Thus, it eliminates merge time 
and consequent expense. 

Input . Input consists of a series of control 
cards specifying parameters such as input, out¬ 
put, and workfile descriptions; sort controls; and 
options in effect. The sort operation is controlled 
by 1 to 12 sort keys and can handle as many as 
9 input files in a single operation. 


Process . As PiSort reads the input file and 
distributes it on a disc workfile, it also performs 
a statistical study of the file sequence. The re¬ 
sults of the statistical analysis are input to sort 
models, simulating the sort possibilities, to se¬ 
lect the most efficient sorting technique. 

The program reads as many blocks as it can 
into the available workspace. If the entire file 
cannot be read into storage, PiSort informs the 
operator. He can cancel the run or he can ignore 
the message, in which case PiSort will sort that 
part of the file in storage. Through this auto¬ 
matic cutoff feature, the entire input file can be 
sorted into pieces, thus eliminating the necessity 
of restarting the application. 

After reading the input file, PiSort performs 
either a single- or multipass sort, based on 
workspace, core memory available, and sequence 
of input data. When enough workspace and core 
memory are available for both techniques, PiSort 
generally selects the multipass approach, which 
is significantly faster than sort 483. PiSort se¬ 
lects the single-pass sort for large files and 
limited work space. In the latter case, sort 483 
will abort. 

Occasionally, PiSort will transfer control 
back to sort 483. For example, a sort control 
card error will cause control to transfer so that 
sort 483 can print error messages described in 
the IBM sort manual. PiSort prints an explanation 
of why the transfer occurred. When control is 
transferred for other than a control card error, 
the sort will continue under sort 483. 

After PiSort has completed the sort, it per¬ 
forms an I/O merge. The resulting file is writ¬ 
ten to tape or disc. PiSort supports spooling 
printer output to either tape or disc; IBM conven¬ 
tions are followed in either case. 

When the PRINT option is used, the following 
information is listed: 

• Control cards. 

• Maximum number of records that can be 
processed in a single- and multipass sort. 

• Total tracks available and needed for a 
given disc type. 

Evaluation . In talking with several PiSort 
users, it becomes obvious that the vendor's 
claims are, in fact, legitimate, although they 
describe a best-case situation. Users state that 
while PiSort requires less storage than sort 483, 
it is not always as low as half that amount. None 
of the users interviewed report a 50% saving in 
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sort time, although all find sort time improved 
over the IBM requirements — between a 23 and 
43% improvement over sort 483. In general, 
they feel a 50% improvement is not an unrealistic 
figure, depending on the characteristics of the 
file to be sorted and the environment in which the 
sort occurs. 

This point takes us to the main problem with 
the package. As far as it goes it performs well, 
but it seems to be designed for the user with an 
unsophisticated system. That is, it sorts only 
fixed length, sequential files. Anyone whose 
files are the least bit complex will not be able to 
use PiSort. In fact, any of the following preclude 
its use: tape workfiles, mixed labels, merge 
only operations, variable length records, Cobol 
SORT verb, AS ADDROUT option, KEYLEN op¬ 
tion, VERIFY option, mixed control field format 
types, CKO CKPT or CHPT in SORT statement, 
EXIT on INPFIL or OUTFIL statement, CAL- 
CAREA option, ALTWK option, BYPASS spec¬ 
ified with disc input, logical record length 
greater than 4, 096 bytes, and overlap of disc 
output with work area. 

In short, PiSort is not the answer to every¬ 
one’s sort requirements. However, if it fits 


one’s needs, it is a definite improvement over 
the IBM alternative. 

SUPPORT 

The lease price includes documentation and 
maintenance. The user can test PiSort process¬ 
ing for a free, 30-day, no-obligation trial period. 

Installation . Installation support from the 
vendor is unnecessary. 

Training. PiSort can be used with no formal 
training of user personnel. 

Documentation. Documentation consists of a 
sales brochure and a reference manual. This 
manual explains the capabilities of PiSort, along 
with operating and installation procedures. 

Maintenance. Package maintenance is in¬ 
cluded in the rental price; updates are supplied 
at no additional cost. 

HEADQUARTERS 

Applied Data Research Corp. 

Route 206 Center 

Princeton, NJ 08540 
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ASSOCIATED COMPUTING SERVICES 

Relo/360 


GENERAL 

Relo/360 is a program designed to make DOS 
object modules relocatable. The package oper¬ 
ates on an IBM System/360 Model 25 and up or 
System/370 under DOS. It requires no change to 
the operating system and uses approximately 2OK 
bytes of core during execution. Relo/360 is writ¬ 
ten in BAL. 

The purchase price is $1,200; lease price is 
$100 per month for a minimum 3-month lease. 
Fifty % of the lease price is applicable toward 
purchase. 

Relo/360 was introduced in January 1972 and 
is currently used in 13 installations. It is avail¬ 
able for immediate delivery. 

DESCRIPTION 

Relo/360 is an enhancement to DOS which al¬ 
lows object modules produced by Cobol, RPG, 
ALC, PL/l, and Fortran compilers to be relo¬ 
catable; that is, they are cataloged once in the 
core image library and subsequently executed in 
any DOS partition. 

Input to Relo/360 is either an existing object 
deck or output from a compiler. Relo/360 adds 
a control section of approximately 150 to 200 
bytes to the beginning of the object module. This 
control section contains data necessary to make 
addresses in the object module relocatable at ex¬ 
ecution time. Relo/360 then saves the module in 
the core image library. 


Using Relo/360 obviates the need to recatalog 
object programs if the supervisor size is in¬ 
creased by a new DOS release or if the partition 
size is modified. Furthermore, disc storage 
space is conserved since each program is retained 
only once rather than two or three times if it is 
to be executed in more than one partition. 

Users we contacted feel the package is invalu¬ 
able for any DOS installation that wants to reduce 
operational overhead, especially since no addi¬ 
tional programming or operations effort is neces- 
sary. They chose Relo/360 over competitive 
packages — which are functionally identical — 
primarily because they had other ACS packages 
and are pleased with the support from ACS 
personnel. 

In short, Relo/360, like its competitors, facil¬ 
itates job scheduling and improves machine usage, 
the primary aims of a DOS relocation package — 
and does it at a very attractive price. 

SUPPORT 

ACS provides Relo/360 as an object deck, along 
with a user's handbook. On-site installation and 
user training are unnecessary. 

The package is guaranteed operational and 
compatible with DOS releases; maintenance to 
this end is covered by the purchase and lease 
prices. Regular updates are not anticipated, ex¬ 
cept as new releases of DOS occur. 
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COMPUTER GUIDANCE ASSOCIATES 
Reloc 


GENERAL 

Reloc enables DOS object modules to be self- 
relocating and executable in any DOS partition. 

The package runs on any model IBM System/ 
360 or 370 under DOS. It does not require addi¬ 
tional peripheral devices other than those nor¬ 
mally used by the installation. Reloc adds ap¬ 
proximately 400 bytes to the size of each object 
program, and is written in IBM assembly 
language. 

The purchase price is $2,200; a 12-month 
lease costs $200 per month. A 50% discount is 
offered on multiple installations. 

Reloc was introduced in May 1971 and cur¬ 
rently is operating in 10 installations. It is 
available for immediate delivery. 

DESCRIPTION 

Reloc is a self-relocator program for the DOS 
multiprogramming environment. It accepts ob¬ 
ject modules from Cobol, Fortran, PL/l, ALC, 
and RPG compilers. 

After Reloc is installed, it operates as part 
of the normal cataloging procedures for the DOS 
library and receives control from DOS when a 
program is to be cataloged. It adds a control 
section to the beginning of this program which 


will resolve all relocatable addresses at execu¬ 
tion time. 

With Reloc, the DOS user no longer has to 
catalog his programs three times to be able to 
execute them in any DOS partition, nor does he 
have to recatalog them when new DOS releases 
increase the size of the supervisor. In addition, 
partition independence facilitates job scheduling 
since DOS programs may be executed at any time 
in any partition when Reloc is used. 

Package users are quite pleased with the 
flexibility Reloc affords their installations. 

Having relocatable DOS programs increases 
throughput and eases their scheduling problems. 

The vendor is helpful when needed but con¬ 
tinuing package support is generally unnecessary. 

Most relocation programs operate in a manner 
similar to Reloc; however, since it is slightly 
less expensive than competitive packages, Reloc 
is more attractive. 

SUPPORT 

The package is unconditionally guaranteed to 
perform as specified; unlimited telephone consul¬ 
tation is supplied at no additional charge. 

The user receives Reloc in the mail along with 
a brochure explaining its capabilities and instal¬ 
lation procedures. Any updates are supplied via 
mail as part of the package. 
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COMRESS 

Amigos 


GENERAL 

Amigos is offered as a substitute for IBM’s 
ISAM file access method. It allows intermixed 
random and sequential processing inCobol, float¬ 
ing storage positioning of file location indexes, 
and dynamic reorganization of files. The pack¬ 
age runs on an IBM System/360 Model 40 and 
above operating under OS or DOS. 

A 3-year license agreement is $17,000 in¬ 
cluding installation; an 18-month lease is $700 
per month plus a $2,000 installation fee; and a 
2-month lease is $1,000 per month plus a $2,000 
installation fee. Various discounts are offered 
for multiple copies. The package is immediately 
available. 

Amigos was first installed in September 1970 
and now has 50 users. Three releases have been 
issued since the original version. 

DESCRIPTION 

Access Method for Indexed Data Generated for 
Operating System/360 (Amigos) was developed by 
Data Art Corporation, a Comress subsidiary, as 
a substitute for IBM’s Index Sequential Access 
Method (ISAM). Functionally, both read and 
write data, block and unblock logical records, 
process standard labels, detect errors and cor¬ 
rect them whenever possible, and provide link¬ 
ages to user error and label routines. Amigos, 
in addition, supports all options of BAL, Cobol, 
PL/l, and Fortran and handles fixed or variable 
length records under OS and DOS. (The variable 
length feature is optional). 


Like ISAM, Amigos uses a nucleus program 
to access files and enter read/write functions, 
and control blocks to hold the parameters con¬ 
cerning each file being controlled. Amigos, how¬ 
ever, uses the same accessing method for ran¬ 
dom and sequential retrievals and employs the 
same control block to handle both types. ISAM 
uses a separate control block and a separate nu¬ 
cleus for each of these types of retrieval. 

The record storage and record searching tech¬ 
niques employed by Amigos contribute heavily to 
its overall efficiency. The record storage tech¬ 
nique is designed to save device read/write time 
during sequential accessing by decreasing the 
time required to retrieve a record from disc. 
This is effected by interleaving the data blocks — 
as opposed to blocking them in sequential order — 
on the disc track. Under interleaving, one data 
block is written in one location and another is 
written, say, two locations away. This allows 
the machine the equivalent of one block and ac¬ 
companying inter re cord gaps to read and process 
the first block before the read head reaches the 
second block. The important factor here is that 
both readings are accomplished during the same 
disc rotation — which isn’t always the case with 
sequential reading. 

Amigos also permits intermixed random and 
sequential processing of the same file by Cobol 
programs, with only one open file required. Pro¬ 
visions have also been made to store data in sec¬ 
ondary disc areas when more space is required 
than allocated. This feature allows the user to 
allocate disc space based on a close estimate of 
the file’s actual size. 


ISAM-TO-AMIGOS CONVERSION 



AMIGOS OPERATION 



SA-1 


Functional Diagram: Comress — Amigos 
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Another effort to increase throughput is re¬ 
flected in the indexing and the block addressing 
techniques employed. The Amigos indexing tech¬ 
nique stores the master index in core (to reduce 
overall search time) and locates the records by 
using a cylinder and block index. This identifies 
the track holding the record and the exact block 
on the track. Generic searches can also be done 
in any of the supported languages. Here, the file 
is scanned and positioned to the first of a partic¬ 
ular class of records; and sequential accesses 
may be made to retrieve all records of a desig¬ 
nated class. 

The file management techniques employed by 
Amigos in both the prime data and overflow 
areas are also aimed at efficiency by reducing 
the number of records in the overflow area, in¬ 
creasing the storage density in these areas, and 
reducing the frequency of file reorganization. In 
both areas, data is stored in blocked form. 

All Amigos files are reorganized dynamically. 
In the prime data area a record designated for 
deletion under Amigos is actually deleted from 
the block, thus creating a gap. If during subse¬ 
quent processing a record is added that will fit 
into a gap, it is added directly. If not, it is 
stored in the overflow area. Since records 
stored in the overflow area are blocked to pro¬ 
vide greater density, less frequent reorganization 
is necessary. When the user-designated upper 
limit for records in the overflow area is reached, 
all records on that cylinder are reorganized into 
the prime data areas and processing continues 
with a newly reorganized cylinder. 

Amigos has a ’’threshold warning” feature 
which automatically alerts the user whenever the 
total amount of disc space available for dynamic 
data set reorganization drops below a previously 
specified level. This prevents unpredictable 
abnormal terminations and allows orderly sched¬ 
uling of file reorganization. 

Any Amigos I/O statements coded for a DOS 
environment will function identically in an OS 
system (and vice versa). Amigos files and pro¬ 


grams can be created under a DOS system and 
subsequently processed under an OS system (and 
vice versa) without modification. 

Amigos is compatible with the IBM 360 operat¬ 
ing system and therefore can be implemented via 
user-coded I/O routines. To convert from ISAM 
to Amigos, however, the program linkage and file 
formats must be changed to meet Amigos require¬ 
ments. Program changes can be attained with no 
modifications to the logic of the application pro¬ 
grams. The only changes necessary are to re¬ 
place ISAM input/output statements with their 
Amigos counterparts on a one-to-one basis. 
With BAL programs, these changes may be 
effected by manually scanning the source listings 
for ISAM I/O statements and replacing them with 
Amigos counterparts. For programs written in 
Cobol, the vendor supplies a program that con¬ 
verts the applicable I/O statements. PL/l and 
Fortran are implemented via an interface. 

Because Amigos is designed to be a complete 
replacement for ISAM, it accepts the same type 
of data. Some modifications to the application 
files, however, are necessary to make them 
compatible with Amigos. The supplier offers a 
program that performs these conversions and 
writes the converted files on disc. Conversion 
requires about 20 minutes per disc pack. 

SUPPORT 

Included in the purchase price are installation 
(only in 3-year license), training, and documen¬ 
tation. The supplier allows up to 5 man-days to 
aid with conversion problems, install the package, 
and train user personnel in system concepts and 
operation. Documentation consists of a users’ 
manual. 

The supplier guarantees that Amigos will op¬ 
erate error free for the life of its installation. 
Most system enhancements are available at no 
additional charge for 3 years, although in some 
cases a nominal fee may be charged for a major 
enhancement. After the first 3 years, updates 
and improvements can be purchased for $2, 500 
per year. 
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DATACHRON 

Jasper 


GENERAL 

The Job Accounting Systems Programs for 
Evaluation and Reporting (JASPER) package is 
a job accounting package for the DOS operation. 
It can be extended to accumulate historic data, 
analyze system usage, and plan effective multi¬ 
programming job mixes. The current version 
operates with any of the popular spooling sys¬ 
tems — GRASP, POWER, ASAP, and SPRINT — 
and with IBM’s CICS. 

Jasper operates on a DOS 360/370 and re¬ 
quires 1 disc drive. It is written primarily in 
BAL and some ANS Cobol. The Data Collection 
Module is available 1 week after receipt of order; 
the remainder of the package is delivered 2 weeks 
after that. 

The perpetual license (1-time fee) for the basic 
job accounting system (including the daily log and 
summary report) is $1, 595. Rental for the basic 
system is $485 per month. Cost for additional 
features is as follows. 


Feature 

License 

Mo. 

Rental 

Exception Report and 
Operator Activity 

$ 250 

$ 15 

System Utilization 

Graph 

250 

15 

Cost Allocation (Sum¬ 
mary and Detail) 

400 

22 

Job Name (Summary 
and Detail) 

550 

30 

Job Characteristics 
(Scheduling Index) 

350 

20 

Device Graph and 

Period Operator 
Activity 

250 

15 

Period Summary 

Report 

200 

12 

Computer Operations 
Master File 
Maintenance 

750 

40 

Full Jasper System 

$4,000 

$200 


Jasper was introduced in January 1972. Since 
that time interfaces were developed for the major 
spooling systems. Datachron guarantees Jasper 
to be operational under all new releases of DOS. 

The package is currently operational in 20 
installations. 

DESCRIPTION 

Admittedly, converting a batch operation to 
multiprogramming is fraught with problems — 
creating an effective job mix, analyzing and re¬ 
fining the system configuration, and allocating 
costs. Jasper is designed to help solve these 
problems. 

The data collection module gathers statistics 
describing each job run. These statistics, main¬ 
tained on the computer operations master file 
(COMF), the heart of Jasper, specify such re¬ 
quirements as: peripherals needed, average run 
time, core size, and percentage compute bound. 
COMF also contains static information about each 
job such as charge code and method of cost 
allocation. 

Other available fields can customize the han¬ 
dling of data for each job, for example: combine 
individual jobs or steps run at different times to 
create an overall job; create YTD averages for 
some jobs and use only the last period’s statistics 
for others; or add a surchage to jobs that use 
special forms or multiple part paper. 

Daily, job execution statistics update the 
COMF. After each run, each job is checked 
against its COMF record to see how it compared 
with previous executions. Run time and CPU 
time are compared to the averages for that job to 
determine if it has been degraded by the mix or 
by other operating difficulties. 

Jobs that vary from their averages by more 
than an allowable percentage are flagged. Thus, 
Jasper does the analyzing and comparing for you 
and pinpoints any areas where problems exist. 

In addition to its basic data handling capabil¬ 
ities, the package can monitor other functions of 
DOS and is customized for each installation from 
the following list of options: 

• Requests entry of system ID and edits for 
validity. 

• Requests entry of operator ID and edits for 
validity. 

• Checks for // JOB card and requests entry 
of JOB NAME is missing. 


Maintenance is supplied free of charge in the 
rental plan. After the first year, $200 per year 
is levied for maintenance under the license plan. 
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• Requests entry of reason for job failure for 
selected IBM cancel codes. 

• Addresses SYSLNK for step names not 
provided by IBM. 

• Edits for valid IPL date and time. 

Since the COMF maintains such detailed cu¬ 
mulative data on every job, it is a simple matter 
to extract appropriate data to solve the problems 
inherent in the transition from batch processing 
to multiprogramming, and then to maintain a 
stable environment. 

Scheduling 

Effective multiprogramming job mixes can be 
set up based on a study of the peripheral require¬ 
ments and operating characteristics of each job. 
In addition, jobs which can run within specific 
peripheral and CPU limitations are highlighted, 
helping you to balance the mix. 

Configuration Analysis 

Because peripheral and partition usage are 
monitored during each shift, you can easily 
match partition availability with devices unas¬ 
signed during that period. Areas of I/O conten¬ 
tion are pinpointed as well as over- and under¬ 
used equipment. 

Cost Allocation 

Customized to your pricing procedures, 
charges can be based on partition or core re¬ 
quired, devices used, run time, CPU time or 
any combination. Facilities are available for 
adding a surcharge for cards punched or lines 
printed, special forms, or multiple-part paper. 

Jasper produces daily detail and analysis 
reports, all of which are customized to your 
needs. The analysis reports point out problem 
areas; while the detail reports supply supporting 
information. Exception reports isolate problem 
jobs within selected exception categories, and 
show actual run times and averages for that job. 
You can set allowable deviations by card input. 

Evaluation . While the basic Jasper package 
performs the job accounting function, its useful¬ 


ness goes way beyond simple job accounting. 
Jasper lets you consistently set up effective job 
mixes — even though peripheral and CPU needs 
change — by identifying jobs with complementary 
requirements. It provides continuous feedback, 
telling you if your jobs are running within ac¬ 
ceptable time limits. And it allocates data pro¬ 
cessing costs to the user departments on a con¬ 
sistent and equitable basis. 

Furthermore, Jasper is an extremely flexible 
system. Changes can be made daily that regulate 
the degree of control, modify COMF parameters, 
and control generation of output reports. 

So, even if all you are interested in is job ac¬ 
counting, Jasper is cheaper than competitive 
packages, and it has the added advantage of built- 
in expandability should your needs change. 

The package users are very enthusiastic about 
Jasper; they believe it’s unbeatable for the price. 
Flexibility and usefulness in running a multipro¬ 
gramming shop were cited as major attractions. 
Further, they feel Jasper creates a negligible 
overhead; especially since every job accounting 
package must perform some kind of record 
keeping. Generally, problems with installation, 
operation, and updates are virtually nil, and 
vendor support is excellent. 

SUPPORT 

The vendor is on-site for 1 day to supply in¬ 
stallation services and training. Services in 
excess of 1 man-day are available at standard 
rates plus expenses. 

Complete system documentation and operating 
instructions are supplied to the user. 

Maintenance is included in the rental agree¬ 
ment. After the first year of a purchased system, 
continued maintenance is supplied for a fee of 
$200 per year. 

HEADQUARTERS 

Datachron Corporation 

174 Fifth Avenue 

New York, NY 10010 
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INNOVATION DATA PROCESSING 

Fast Dump Restore 


GENERAL 

Fast Dump Restore (FDR) is a utility program 
that dumps 2314, 2319, and 3330 disc packs or 
their plug-compatible equivalents to magnetic 
tape and restores packs from the tapes. 

FDR runs on an IBM System/360 Model 40 and 
up or a System/370 Model 135 and up under PCP, 
OS/MFT, OS/MVT, or OS/VS1. It requires 64K 
bytes of core for 2314 discs and 100K for 3330 
discs. Source language is assembler. 

The 2314 or 3330 version of FDR costs $990 
for unlimited use includes an object deck, user 
documentation, and a source listing of either 
the 2314 or 3330 version. For each additional 
computer system, the price of either version of 
FDR is $500. To add the other version for any 
system for which one version has been purchased 
costs an additional $100. A copy of the source 
code on tape costs an additional $50. 

Introduced in July 1972, FDR is operational 
in over 75 installations. New features are added 
periodically and are supplied to users generally 
without charge. Significant enhancements are 
offered at a slight fee to users. A stand-alone 
restore program (FDR-SAR) is available. 

Innovation Data Processing supplies such 
products and services as hardware and software 
measurement services designed to save the com¬ 
puter user time and money. The vendor also 
provides application customization services for 
data base applications, educational programs 
for personnel at all levels, and configuration of 
hardware/software systems for complex in¬ 
stallations, conversions, and networks. 

DESCRIPTION 

FDR is designed to replace the dump and 
restore functions of IBM T s IEHDASDR. The 
vendor claims that FDR is significantly faster, 
uses less tape, and is more reliable in handling 
bad tracks. 

Vendor’s comparison figures seem to back 
up the claim. Both packages dumped and re¬ 
stored a full disc pack with other jobs active in 
the system, causing interference on the channel, 
control unit, and disc spindle during the opera¬ 
tion. FDR dumped the disc packs in 15 to 30% 
of the time required by IEHDASDR and restored 
them faster than the dump operation. 

FDR’s speed is achieved by utilizing dynamic 
buffer management and highly overlapped tape 
and disc I/O, as compared with IEHDASDR’s 


track-by-track, unoverlapped, serial operation. 
FDR reduces disc channel contention by pro¬ 
cessing all tracks of a cylinder without losing a 
revolution. Speed is limited only by the data 
transfer rate of the tape drive. 

FDR employs single-record track formatting 
and blocking techniques to improve tape transfer 
speed and reduce tape channel contention. This 
method requires 40% less tape than that used by 
IEHDASDR and reduces tape mounts for multiple 
reels. 

During a restore operation, FDR uses the 
alternate track assignments, if any, of the pack 
to which it restores. IEHDASDR retains the 
alternate track assignment of the disc that was 
originally dumped, which can cause data to be 
written on bad tracks of the new disc and thus 
become inaccessible. FDR eliminates this prob¬ 
lem entirely. 

FDR also offers the option of restoring the 
original volume serial number of the dumped pack 
to the restored pack or retaining the volume 
serial number of the new pack. 

FDR2314 has 5 options: 

• Dump 1 pack; core required is 64 to 68K 
depending upon OS options, no PARM is 
used. 

• Dump several packs (up to 9) serially; core 
required is 64 to 68K depending upon OS 
options; no PARM is used. 

• Dump several packs (up to 9) concurrently; 
core required is 64 to 68K for the first 
pack, depending upon OS options, plus 6OK 
for each additional pack. PARM=A is used. 
This is the ATTACH option, for use under 
MVT or MFT with subtasking. 

• Restore 1 pack, giving the restored pack 
the volume serial of the dumped pack; core 
required is 54 to 56K depending upon OS 
options. PARM=R is required. 

• Restore 1 pack, retaining the volume se¬ 
rial of the restored pack; core required is 
54 to 56K depending upon OS options. 
PARM=N is required. 

FDR3330 has 4 options: 

• Dump 1 pack; core required is 10OK. No 
PARM is used. 

• Dump several packs (up to 9) serially; 
core required is 100K. No PARM is used. 
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• Restore 1 pack, giving the restored pack 
the volume serial of the dumped pack; core 
required is 10OK. PARM=R is required. 

• Restore 1 pack, retaining the volume seri¬ 
al of the restored pack; core required is 
100K. PARM=N is required. 

Input . In addition to the tape and disc in¬ 
volved in the dump or restore operation, FDR 
requires a group of JCL statements, which de¬ 
scribe the job and the I/O units involved. 

Process . FDR reads and validates the JCL. 
Missing or erroneous statements cause the job 
to terminate (as do hardware malfunctions) once 
FDR has begun processing. 

Any data written according to standard IBM 
programming specifications, including all stan¬ 
dard access methods, can appear on the disc 
pack being dumped to tape. 

During a restore operation, FDR handles in¬ 
put tapes created by FDR or IEHDASDR. Upon 
detecting an IEHDASDR tape, FDR sets up the 
necessary control information and invokes 
IEHDASDR. Therefore, FDR can be used for all 
dumping and restoring; the user need not dis¬ 
tinguish between FDR and IEHDASDR backup 
tapes. 

If it encounters an abnormal condition, FDR 
enters diagnostic routines to assess the problem 
and report the problem to the user. FDR will 
attempt to complete the dump or restore on 
minor problems. 

Output . In addition to the tape (containing 
the contents of the dumped disc) or the restored 


disc, FDR prints diagnostic and console messages 
to inform the operator of a completed job or any 
unusual conditions that occurred. 

Evaluation . Using IEHDASDR as a yardstick, 
FDR offers several advantages. Because of 
FDR’s speed, computer processing time is saved; 
it also uses 40% less tape than IEHDASDR. With 
these points in mind, a user can restore a disc 
pack from tape, run his job, and dump the pack 
to a new tape, thus saving disc space. Using 
disc in this manner eliminates time-consuming 
disc mounting and dismounting. 

FDR does not offer the partial dump facility 
found in IEHDASDR: According to package users 
this is not a serious problem because FDR's 
speed is so fast that dumping the entire volume 
is frequently accomplished in less time than 
dumping a partial volume using the OS utility. 

Users interviewed believe FDR operates in 10 
to 35% of the time that IEHDASDR requires, de¬ 
pending on the tape density and number of tracks. 
They feel it is an invaluable moneys aver for a 
very reasonable price. 

SUPPORT 

Included in the package price is a 30-day free 
trial, as well as documentation and maintenance. 
The user is responsible for installing FDR and 
briefing his personnel in its use. 

Documentation consists of a concise package 
description detailing capabilities, installation, 
and operation. 

Maintenance and enhancements are provided 
free of charge. 
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JASON DATA SERVICES 

Sprint 


GENERAL 

Sprint is an automatic spooling system for the 
IBM 360/370. It operates asynchronously with a 
problem program, resides in FI, F2, or outside 
of the three normal DOS partitions, and uses the 
standard unmodified DOS supervisor in conjunc¬ 
tion with its own supervisor. 

The system runs on IBM 360/22 and up or 370 
(DOS or DOS/VS) with a minimum of 32K bytes of 
main core storage. It requires 2K to 4K bytes 
for tape spooling and 4K to 12K per partition for 
the disc spooling programs. Minimum auxiliary 
storage is four cylinders per reader queue and 
10 cylinders per printer queue (2311, 2314, or 
3330). 

Rental is $95.00 per month for the basic pack¬ 
age which includes reader, printer, and punch 
spooling with job accounting. Rental is $180.00 
per month if multiple partition spooling, device 
address independence, or relocating loader are 
desired. A perpetual lease option is available. 
Thirty day free trial is also offered. 

DESCRIPTION 

Spooling is a technique that has been used for 
some time to decrease problem program execu¬ 
tion time by intercepting supervisor calls (SVCs) 
for unit record devices and placing the output data 
on a magnetic storage device. After the problem 
runs to completion, the data is retrieved from 
storage and printed. Quite simple? Yes. But 
also quite costly in auxiliary storage space, the 
amount of time required to ultimately print the 
data, and the overhead incurred by having print¬ 
ers and punches sitting idle while the data is being 
spooled. In fact, conventional spooling is so time 
consuming, some packages using it fail to men¬ 
tion print times in performance data. 

To counter conventional spooling deficiencies, 
a number of spooling packages have recently 
emerged. These systems generally use the same 
techniques as conventional spooling to transfer 
record data to and from auxiliary storage, but 
they differ in the way I/O commands are handled 
and records are sorted. Many of the newer sys¬ 
tems either use their own supervisor or modify 
the host system supervisor. Sprint uses its own 
supervisor in conjunction with an unmodified 
standard DOS supervisor. 

Sprint is comprised of two basic programs. 

The first is a tape spool program which dynami¬ 
cally allocates buffers and is completely self- 
relocatable. Core requirements for this program 
are between 2K and 4K bytes. The second is a 


disc spool program which also dynamically allo¬ 
cates buffers and is completely self-relocatable 
but requires between 4K to 12K bytes of main 
core per partition spooled. Additional modules 
support Device Address Independence, Job Ac¬ 
counting, Relocatable Loader, and Partition 
Balancing. 

The Sprint programs reside in a high core 
(FI, F2) or outside normal DOS partitions and 
spool all I/O to or from readers, printers, and 
punches. The system does require a multipro¬ 
gramming supervisor and storage protect feature. 

A principal feature of Sprint is its ability to 
output data to a buffer area and then ultimately 
to a unit record device while the problem pro¬ 
gram is still executing. This asynchronous oper¬ 
ation is possible due to the way the Sprint super¬ 
visor handles I/O interrupts. In operation, the 
problem program issues supervisor calls (SVCs) 
in the usual manner, and these calls are routinely 
analyzed by the host supervisor. It is at this point 
that the Sprint supervisor comes into operation. 
The program simply examines the address of the 
output device to determine if it is under its con¬ 
trol. If so, the data is placed on a predesignated 
disc or tape; if not, control is returned to the 
DOS supervisor and operations continue in a nor¬ 
mal fashion. 

Systems of this type usually assign a unit rec¬ 
ord device to a specific buffer storage area, load 
data into the buffer, and subsequently output the 
buffer contents to the device while the problem 
program is still executing. 

Generally the data being spooled is loaded 
into a core buffer with overflow data being placed 
on disc or tape. (Overflow occurs because the 
unit record device is too slow to service the buff¬ 
er. ) Data is printed a line at a time until the 
buffer contents have been exhausted. The con¬ 
tents of the core buffer are then dumped to disc 
or tape and new data is loaded. Sprint, however, 
uses a different approach. Instead of loading data 
into the core output buffer directly, it records it 
in disc or tape storage first. After one disc track 
has been accumulated, the data is loaded to the 
core buffer and the output operation begins. 

The size of the buffers used for storing output 
records is entirely up to the user, but the system 
only works with blocked physical records. Thus, 
for best utilization of disc or tape and core and 
for reduced seek times, one would be wise to 
block by disc track. This allows the use of 
smaller buffers without degradation since the data 
transfer from the buffer to the unit record device 
is limited by the speed of the device. 
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In addition to disc spooling. Sprint spools to 
magnetic tape. The technique used to accomplish 
this is the conventional DOS method, but Sprint is 
able to use tape marks to denote individual files 
within a volume and force an end of volume con¬ 
dition before the end of volume reflective spot is 
sensed. 

Sprint has a forms alignment routine which 
enables print carriage characteristics to be con¬ 
veyed to the spool routine. As lines are spooled 
out, the theoretical position within a page is 
maintained allowing proper handling of forms 
overflow. The forms alignment routine permits 
the perpetual reprinting of one page of print, 
pausing to allow adjustment until the operator is 
satisfied with the alignment. A printer back¬ 
spacing feature allows reprinting of pages in the 
event of a forms jam. 

The system also offers priority, job bypass 
and job accounting routines, device address in¬ 
dependence, a relocating loader, and partition 
balancing features. The priority routines allow 
the user to suspend processing of the spool and 
to enable the background partition to function 
normally. The bypass allows the operator to by¬ 
pass jobs he does not want to print or punch. 

Sprint’s accounting package is actually the 
standard IBM job accounting program; Jason 
merely supplies code that lets a user activate it. 
Information such as job name, user information 
(16 bytes taken from each job card), partition 
ID, cancel code, record type (job step = S, last 
step of job = L), start time, phase name, high 
core used, CPU time, overhead time, stop time, 
all bound time, start I/O count, and total pages 
printed is given. Note that a forms inventory can 
be maintained with this information. 

The device address independence feature elim¬ 
inates the DOS portability problem by obviating 
the need to have actual device addresses in 
ASSIGN cards. The user may refer to logical de¬ 
vices such as ’’DOl” instead of ”130”. Sprint 
dynamically substitutes actual address at execu¬ 
tion time. All substitutions are based upon the 
partition being used. 

The relocating loader makes all user pro¬ 
grams self-relocating and also allows the user 
to better manage his program library by main¬ 
taining such information as the date cataloged 
and the date last used. The relocating loader 
handles the ANS Cobol Sort verb, requires no 
changes to the JCL, and does not increase the 
size of the user’s program. 


The relocating loader is built around a sepa¬ 
rate core-image load file, a single extent com¬ 
posed of three parts: the Directory, Phase 
Headers, and Phases. 

The Directory consists of 1034 or 1100 byte 
blocks, each containing 22-byte phase entries in 
collating sequence by phase name. The first rec¬ 
ord in the first block is a library status record 
and contains information such as number of ac¬ 
tive entries, number deleted, and so forth. A 
key associated with each block shows the name of 
the last phase in the block. Each phase entry 
points to the phase header and the phase itself. 

A typical allocation of 10 2314 tracks yields a 
capacity of 2900 phase entries. The directory 
must begin on a cylinder boundary and has a 
maximum size of one cylinder. 

The Phase Headers precede each phase in the 
library and are of an undefined record format 
ranging from 51 to 1078 bytes in length. They con¬ 
tain information such as date entered, date last 
used, user information from the job card, and 
relocation pointers. This header is used by 
Sprint and is not loaded into the user’s partition. 

The phases themselves follow the phase head¬ 
ers. These records are written in an undefined 
format and range in length from one byte up to an 
entire track. They are a mirror image of the 
phase just as it was link edited. 

The Partition Balancing feature essentially is 
an algorithm that keeps track of each executing 
partition and ensures that a high priority partition 
does not lockout a lower priority partition. 

Sprint also offers another feature called 
Marvel, which allows one or more disc spooling 
programs to operate outside of a normal parti¬ 
tion. Marvel begins execution as a normal FI 
program, attaches the disc spooler programs, 
and then attaches a special monitor to allocate 
the card reader to different spooler programs. 
After rotating partition priorities, Marvel goes 
to EOJ. 

Evaluation 

As spooling programs go. Sprint is not exactly 
rudimentary. It is not, however, as sophisticated 
as some of its competitors, for example, Soft¬ 
ware Design’s GRASP. 

Sprint, basically, provides most of the spool¬ 
ing capabilities one should need, plus a few very 
nice features such as device address indepen¬ 
dence, relocating loader, and partition balancing. 
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The latter feature is worth noting for it prohibits 
high priority programs — especially those with 
well balanced CPU and I/O times — from freez¬ 
ing out lower priority jobs. 

Sprint does have one potentially significant 
drawback; however, it does not support RJE. If 
your future needs appear to lean toward remote 
job entry, you'd better think twice before you buy 
Sprint. We say think twice because even if RJE 
is in your future, your present needs can be met 
quite nicely with Sprint. And for $95.00 per 
month rental you can’t go too wrong. 

The users we spoke to agree Sprint meets its 
specs. No real problems have occurred. 

Input . Sprint inputs consist of data records 
loaded to buffer storage areas contained in core 
and/or on disc. 

Process . Data bound for a unit record device 
is first loaded to disc where it remains until a 
track is filled. At that time the data is loaded to 
a core buffer which has a unit record device as¬ 
sociated with it; all print lines are command- 
chained together, and one SVC is issued to print 
the entire buffer. With Sprint the printer and the 
punch share buffers. 

Sprint also permits data bound for different 
types of unit record devices to be intermixed on 
the same track of the same disc. The advantage 
of having more than one type of device sharing 
the same file is that as blocks are written to the 
file for various devices, they will be likely to fall 
in the same cylinder thereby reducing the seek 
time that would be normal when more than one 
spool is being utilized on the same physical disc 
unit. However, when data is being transferred 


to core for output, it must be distributed among 
the buffers associated with each device. 

This method can, however, reduce the effi¬ 
ciency of disc space utilization because when low- 
usage spool devices are mixed with high-usage 
spool devices, the low-usage device is not oper¬ 
ational for some reason. That situation causes 
its records to be temporarily irretrievable. 

Output . Output can be to card, tape, printer, 
or disc. If more than one printed or punched 
copy is required, the user may designate up to 
9999 copies. 

SUPPORT 

The rental price includes installation and 
documentation. 

Installation and Training . The user should be 
able to install the system and train his own 
people. 

Documentation . The vendor supplies object 
code and operator instructions. A combination 
programmer's manual and installation guide has 
been prepared and should obviate the need for on¬ 
site vendor training and installation assistance. 

Maintenance . Sprint carries no guarantee 
against source code bugs, and maintenance is 
included in the rental. 

HEADQUARTERS 

Jason Data Services 

903 East North Street 

Manteca CA 95336 
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MACRO SERVICES 

DEEP/360 


GENERAL 

Data Exception Error Protection (DEEP/360) 
isolates a data exception before it cancels execu¬ 
tion, attempts to correct it, and continues with 
execution of a Cobol or BAL program. It runs on 
an IBM 360 Model 25 and up under DOS and re¬ 
quires 3K bytes of core storage and 1 printer. 
DEEP/360 is one program written in assembly 
language. Purchase price is $225. 

DESCRIPTION 

DEEP/360 is called by the operating system 
supervisor to isolate data exception errors; the 
most common errors found in program testing 
before the exception can cause termination of 
program execution. When DEEP/360 traps an 
exception, it tries to correct the error to pre¬ 
vent subsequent data exceptions and then contin¬ 
ues with program execution. 

DEEP/360 must be called twice whenever it 
is used, initially to establish its linkage with the 
supervisor and as a closing step to display the 
end-of-job error totals. For the first 10 unique 
core locations at which data exceptions occur, a 
console message is printed; additional errors at 
those locations are counted but not printed. Er¬ 
rors occurring at other core locations cause a 
message to be printed for each error. After 
every 10 console messages, the user can sup¬ 
press all additional messages. At end-of-job the 
error counts for the first 10 error locations are 
displayed. 

Input . To use DEEP/360, the user codes 2 
subroutine calls in his program. He must also 
insert the proper control card in the link edit job 
stream. 

Process . Each time a data exception occurs, 
control is passed by the supervisor to DEEP/360 
to examine the suspected data. The routine cor¬ 
rects the data at fault, prints the core location, 
and notifies the user of the corrective action 


taken; it also prints the contents of the erroneous 
data field before and after correction. DEEP/ 

360 then reexecutes the instruction and proceeds 
with program execution. If DEEP/360 cannot 
find the error or cannot correct it, it displays a 
message and bypasses the instruction in an effort 
to continue execution. 

At the end of the program, the second call to 
DEEP/360 causes the routine to print out a sum¬ 
mary of the checks occurring during that pro¬ 
gram’s execution. 

If the operator suppresses error notification, 
no messages of any kind are printed when a data 
exception occurs. However, fields are still cor¬ 
rected, error totals kept, and execution continued. 

Output . Output from DEEP/360 is a listing of 
the core locations at which a data exception has 
occurred. For each location, the data field is 
printed as it appeared when causing the error and 
in its corrected form. At end of job, DEEP/360 
provides a total of the data exceptions occurring 
at the first 10 unique locations and indicates 
whether other exceptions occurred. 

SUPPORT 

Brief descriptive material and telephone con¬ 
sultation are supplied by the vendor. No vendor 
support is necessary to install the package, and 
no training of user personnel is required. 

Brief program documentation describing the 
functions, inputs, processing, and outputs is 
supplied by the vendor. DEEP/360 is indefi¬ 
nitely supported by way of telephone and mail 
consultation. Updates and bulletins are mailed 
to the user at no charge. 

HEADQUARTERS 

Macro Services 

373 Park Avenue South 

New York NY 10016 
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MARCUS POWELL ASSOCIATES 
Anyplace II 


GENERAL 

Anyplace II is an IBM System/360 or 370 DOS 
enhancement designed to allow user programs 
and system software to automatically relocate and 
run in any suitable partition. The package works 
with Cobol, PL/l, Fortran, and RPG object 
modules constructed as monolithic or multiphase. 

The minimum partition size for Anyplace II is 
10K bytes on either the System/360 or 370. Like 
many of its competitors, the package does append 
code to the DOS supervisor; in the case of Any¬ 
place II this amounts to about 150 bytes. 

Anyplace II is priced at $1,800; additional 
installations cost $100 each. A 30-day free trial 
is offered. 

If one were to perform a f ’flack M survey of 
DOS users, high on the gripe list would be non- 
relocatability. Simply stated, this means that 
once an object module is designated to run in a 
particular partition, it can T t be relocated to rim 
in another. Aside from inconvenience, the lack 
of a relocatability feature can result in wasted 
resources and reduced job throughput. This is 
particularly true when a partition of suitable 
size, with acceptable peripherals, becomes 
available. Programs in the core image library 
can’t use it because they’re not assigned to that 
area. Thus the partition sits empty and waiting 
jobs continue to wait. 

To get around this limitation, many users 
resort to redundant cataloging of the same pro¬ 
gram in the core image library. Although this 
practice does solve the principal problem, it also 
creates a myriad of smaller ones. For example, 
when the supervisor and/or partition size 
changes, recataloging is necessary. Also, re¬ 
dundant cataloging requires more disc space and 
separate JCL. 

With Release 28 of DOS (called DOS/VS) IBM 
has solved the nonrelocatability problem — along 
with a number of other DOS shortcomings. But 
DOS/VS is offered free only to System/370 Model 
115 through 158 users, a restriction many believe 
to be a marketing ploy to get System/360 users to 
trade up to the System/370 or move to OS. These 
alternatives, however, are unacceptable to many 
users who either own, or like, their Models 30, 


40, and 50. And running OS on anything less 
than a Model 50 is pure folly. 

The most plausible option available to the for¬ 
gotten many is to turn to independently developed 
packages that offer a relocatability feature. Sys¬ 
tems such as GRASP and EDOS posses it, but 
only as part of a large sophisticated system. 

Then there are the simple ’’bread and butter” 
packages like Anyplace II which allow relocation — 
that’s all. 

DESCRIPTION 

Anyplace II functions like a linkage editor pre¬ 
processor, adds a control section to each phase 
of a program, and appends code (actually a seg¬ 
ment) to the DOS supervisor — all in an effort to 
allow monolithic or multiphase programs to be 
relocatable. In operation, Anyplace II processes 
linkage editor inputs to the SYSLNK file and the 
core image library to create a new SYSLNK in¬ 
put file, which is then link edited to produce pro¬ 
grams that are self-relocating. 

Anyplace II requires no changes to the problem 
programs or to the linkage editor. The segment 
appended to the DOS supervisor, however, does 
modify it somewhat. This code is added at 
SYSGEN time and consists of either a macro 
called SGANP (for system generation anyplace) 
or a separate initializer called ANYINIT (for 
anyplace initializer). 

During program execution, the appended 
supervisor segment examines each object module 
to determine if it has a self-relocatable flag. If 
so, the module is loaded into memory at the be¬ 
ginning of any suitable partition. ADCONs are 
resolved by the control section. After the pro¬ 
gram is loaded, the control partition and reloca¬ 
tion table are stripped off and the program is 
returned to its original size. 

FEES AND SUPPORT 

The purchase price of the package includes 
source decks, documentation, and maintenance 
for 1 year. 

HEADQUARTERS 

Marcus Powell Associates 

2694 Doidge Avenue 

Pinole, CA 94564 
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SOFTWARE DESIGN 
GRASP 


GENERAL 

GRASP is an automatic spooling system for 
the IBM 360 which operates asynchronously with 
problem programs, resides in a foreground par¬ 
tition, and uses its own supervisor. It handles 
local and remote batch jobs in multiprocessing 
mode. 

The system runs on IBM 360 and 370 (DOS) 
and up with a minimum of 32K bytes of main 
core storage and requires a minimum of 6K bytes 
for its partition, plus at least 20 cylinders of a 
Model 2311, 2314, or 3330 Disk Drive of auxiliary 
storage. Source language is BAL. 

Leases are $300 a month for the basic version 
and $630 a month for the extended version. 


PACKAGE DESCRIPTION 

Spooling is a technique that has been used for 
some time to decrease problem program execu¬ 
tion time by intercepting supervisor calls (SVCs) 
for unit record devices and placing the output data 
on a magnetic storage device. After the problem 
program runs to completion, the data is retrieved 
from storage and printed. Quite simple? Yes. 
But also quite costly in auxiliary storage space, 
the amount of time required to ultimately print 
the data, and the overhead incurred by having 
printers and punches sitting idle while the data is 
being spooled. In fact, conventional spooling is 
so time consuming, some packages using it fail 
to mention print times in performance data. 

To counter conventional spooling deficiencies, 
a number of spooling packages have emerged 
recently. These systems generally use the same 
techniques as conventional spooling to transfer 
record data to and from auxiliary storage but 
differ in the way I/O commands are handled and 
the way records are sorted. Many of the newer 
systems either use their own supervisor or mod¬ 
ify the host system supervisor. GRASP uses its 
own supervisor. 

GRASP, one of the older spooling packages 
(introduced in 1968), is a combination spooling 
and buffering system with additional system con¬ 
trol and monitoring features that are seldom in¬ 
cluded in this type of package. Its program re¬ 
quires between 6K to 10K bytes of main core and 
resides in a foreground partition; in operation it 
buffers and/or spools all I/O to or from readers, 
printers, and punches under its control to back¬ 
ground partitions or disc storage. Extended 
GRASP supports any type of printer, card reader, 
card punch, card reader/punch, paper tape 
reader, or magnetic cartridge reader in any 


desired number and combination. In addition, 
pseudo devices may be defined to simulate addi¬ 
tional unit records. Each spool file may be as¬ 
sociated with as many spoolable devices as 
desired. 

A principal feature of GRASP is its ability to 
output data to a unit record device while the 
problem program is still executing. This is pos¬ 
sible due to the way the GRASP supervisor han¬ 
dles I/O interrupts. The supervisor itself re¬ 
sides in a high-core foreground partition, thus 
making it appear as though it were a fourth DOS 
partition. It in no way interferes with the host 
supervisor, but rather works in conjunction with 
it. No changes to the problem programs are re¬ 
quired either. 

In operation, the problem program issues 
supervisor calls (SVCs) in the usual manner, 
and these calls are routinely analyzed by the 
host supervisor. After determining which I/O 
device should receive the data, a normal start 
I/O command is issued. (A start I/O instruction 
activates an I/O channel and also indicates by 
address which I/O device is to receive the data.) 
It is at this point the GRASP supervisor comes 
into operation. When the GRASP program is 
being specified for a particular application, a 
phantom address is associated with each device 
address being used. Upon issue of this address 
by the start I/O, the GRASP supervisor inter¬ 
cepts it and in turn branches it to the phantom 
address. 

The phantom address has a particular buffer 
associated with it. Transfer of data to the buffer 
is accomplished through GRASP-generated chan¬ 
nel command words. To keep the system in the 
proper state during this operation, GRASP issues 
a modified PSW. After the data has been trans¬ 
ferred, the old PSW is restored. Wdien the buffer 
is full, its contents are sent to the appropriate 
unit record device. 

The system offers a number of noteworthy 
features. For example, GRASP provides ac¬ 
counting reports with the expected information 
on numbers of cards read, cards punched, lines 
and pages printed, and job times. However, 
more sophisticated information is gathered about 
each job (or job step if desired), such as data on 
operator efficiency, CPU utilization, interparti¬ 
tion interference, counts of phase loads, amount 
of core used, I/O counts on all active SYS units, 
and so on. In addition, the user may gain control 
at several points (own-code hooks) so that details 
such as department code or cost code may be 
recorded. Cumulative records of this type can 
also be built up on tape or disc for periodic 
analysis. 
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GRASP also provides a program relocatability 
feature through its resident program loader. With 
it, all user programs, no matter in which lan¬ 
guage they are written, are executable in any par¬ 
tition. Programs reside in private load libraries 
in a form that allows considerable saving of space 
compared with core image library format. 

Remote terminals are supported precisely as 
if they were local card readers/printers/punches. 
Total core requirement for GRASP with RJE is 
6K plus 2K per spooled device (local or remote). 
Devices supported as remote terminals include 
IBM 2770, 2780, System/360 Model 20, System/ 
360 Models 25 and up, and System/3. 

GRASP enables spooling to tape concurrently 
with or instead of its normal disc buffering/ 
spooling. This facility provides backup for large 
reports, as well as flexibility in scheduling where 
and when a large report should be printed. 

If desired, GRASP runs in an independent par¬ 
tition. The package will also function with up to 
8 subtasks in separate partitions in a multitasking 
environment. 

Automatic job scheduling is also a standard 
feature. In this case the system automatically 
selects from its spooled-in streams the job of 
highest priority, whether submitted locally or 
through a remote terminal. The selected job is 
dispatched into the first available partition; re¬ 
location is performed; device-type assignments 
are resolved; and the operator is informed of 
job setup. Users can restrict certain jobs to 
designated partitions. 

Dynamic device addressing permits the user 
to make assignments to a device type, leaving 
the selection of the specific device to GRASP. 

This permits more efficient use of a smaller 
number of peripherals serving multiple partitions. 

Two other notable features of GRASP that were 
not part of the original system are partition bal¬ 
ancing and transient code retention. With parti¬ 
tion balancing the system continually monitors 
the relative CPU-boundness of processing par¬ 
titions and dynamically alters the partition prior¬ 
ities to attain maximum throughput. This is an 
excellent feature. Partition balancing itself is a 
relatively new concept to DOS but is not restricted 
to GRASP. In essence, the balancing is done to 
prohibit both I/O-bound and CPU-bound jobs from 
monopolizing the machine. The net effect is that 
high priority f ’machine eating” jobs won’t be able 
to freeze out lower priority jobs. 


With transient code retention, GRASP holds 
a stack of the most commonly used transients in 
its partition and moves them to the transient area 
for execution when requested. This results in 
large savings, especially for ISAM users or in¬ 
stallations running a large number of short jobs. 

GRASP also provides procedure libraries, 
wherein procedures may be cataloged once and 
extracted for repeated use. This capability is 
useful for controlling, changing, and protecting 
run decks. 

An automatic paper alignment feature allows 
stationery changes and controls lining-up re¬ 
quirements, even for programs requiring several 
switches of paper in mid-execution. A backspace 
command allows reprinting of lines lost due to 
paper wrecks. 

GRASP accommodates IBM 1400 Series work 
under control of any of the DOS emulator pro¬ 
grams. No alterations are required to these 
programs. 

The basic version of GRASP is available for 
one of the following configurations: one printer 
only; one printer and one punch; one printer and 
one card reader; or one printer, one reader, and 
one punch. Options such as accounting routines, 
attached subtasks, self-relocating linkage editor 
and load routines, remote job entry support, and 
simultaneous printer tape output are available. 

As of this writing, GRASP has approximately 
300 users; we had an opportunity to talk to a few 
to gain their impression of the system. They 
were extremely enthusiastic about GRASP and its 
vendor. The package, according to them, works 
as advertised and has resulted in considerable 
time savings. We only heard one complaint about 
GRASP’S operation, which was that you cannot 
pocket select on a reader if spooling is being 
used. GRASP, however, does offer the capability 
to close off the reader from the spooling program, 
thus permitting it to run under normal DOS. 

Input . System inputs consist of the I/O re¬ 
quests intercepted from the host operating sys¬ 
tem, any user own-coded routines, and the actual 
data to be output. 

Process . The data bound for a unit record 
device is first loaded into a designated buffer 
area, which has a particular device associated 
with it. As soon as the buffer is fully loaded, a 
GRASP channel command word is issued allowing 
the output of data to that device. If the speed of 
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the output device is too slow to handle the buffer 
(which is often the case), the data overflows to a 
specified disc. When the buffer completely emp¬ 
ties, the disc loads it with the next print lines. 

A typical buffer can hold between 15 to 40 such 
lines. 

Output . Output may be to card, tape, printer, 
or disc. If more than one printed copy is re¬ 
quired, the user may designate any number up to 
99. 

FEES AND SUPPORT 

A one-time fee plus per diem is levied to in¬ 
stall the package and train user personnel; pack¬ 
age cost includes a lifetime guarantee against 
source code bugs. 

Installation. About one-half man-day is con¬ 
sidered adequate to tailor the system to the par¬ 
ticular application and install it. 


Training . Formal instruction covers operator 
training and programmer orientation. 


Documentation . GRASP is delivered in object 
code. Documentation, consisting of a system 
overview and user and programmer manuals, is 
produced by the user f s computer through self¬ 
loading vendor-supplied tapes. For the most part 
the manuals are thorough and to the point. 


Maintenance . The package is fully guaranteed 
for the life of the installation. Enhancements are 
offered free of charge. 


HEADQUARTERS 

Software Design Inc. 
872 Hinckley Rd. 
Burlingame CA 94010 
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SOFTWARE TECHNIQUES 

Prtfast 


GENERAL 

Prtfast is a printing package that provides 
maximum overlap of processing and printing for 
Cobol or assembly language programs. 

It runs on any IBM System/360 under DOS or 
TOS (release 16 and later) with an IBM 1403, 

1443, or 3211 printer and a minimum of 456 
bytes of storage. 

Immediately available, the package can be 
purchased for a one-time 99-year lease price of 
$1,250. 

Prtfast was first installed in March 1969 and 
now has 28 users. Since the original version, 
five new releases have been issued. 

DESCRIPTION 

Prtfast package speeds the printing performed 
in batch or multiprogramming environments. The 
system has three components: a Prtfast macro, 
which formulates Prtfast logic modules; a routine 
that automatically opens the output file; and an 
automatic overlay for effecting device indepen¬ 
dence. Prtfast operates by increasing the num¬ 
ber of buffers to enable a greater amount of 
printing while program execution continues unin¬ 
terrupted. Improved logic enables the user T s 
processing program to be as many logical rec¬ 
ords ahead of physical printing as desired. 

Prtfast is a self-relocating program which 
can be used with any program written in Cobol 
or assembly language. It does not require a 
special supervisor or changes to any IBM inter¬ 
nal software. The only changes needed to use 
Prtfast are conversion of all PUT and WRITE 
statements to CALL statements in the application 
programs. 


Since Prtfast replaces the manufacturers 
I/O control system, it builds its own logic module 
from input parameters. Thus, the Cobol pro¬ 
grammer does not have to code a SELECT state¬ 
ment or a file definition for the output file. How¬ 
ever, Prtfast does not detect end of page; the 
programmer must determine page overflow via 
line counting. 

Normally, the output device is a printer. 
However, the Prtfast device-independent feature 
permits the output device to be a 2400 Series tape 
drive or a disc if the device is assigned to 
SYSLST. If a system has multiple printers, they 
may be run simultaneously as long as each printer 
has its own logic module. 

The supplier claims a 25% increase in output 
processing can be expected when Prtfast is used. 
This figure is greatly influenced by the speed of 
the input device and the access method used on 
the input and output files. 

Input. To assemble the Prtfast module, the 
user specifies: module name, record size, num¬ 
ber of buffers, indication of whether separate as¬ 
sembly is to occur, device address, indication 
of whether relocation is to occur at open time, 
and type of forms control character. The Prtfast 
logic modules can be reassembled whenever the 
user wishes, but do not have to be reassembled 
with each run. 

Once the Prtfast modules are assembled and 
cataloged, the user simply issues a CALL macro 
in his BAL programs or a CALL statement in his 
Cobol programs. With each request a user- 
specified parameter is passed consisting of a 
valid ASA or System/360 printer command code 
and the data to be placed into the buffer. 

Process . Before Prtfast can process output, 
the Prtfast logic module must be assembled. If 
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a module name is not supplied, Prtfast generates 
one reflecting some of the characteristics of the 
module. 

The first time the module is called, a Prtfast 
routine opens the output file, verifies device type 
and assignment, and relocates address constants 
if required. It also compares the number of 
buffers requested in the Prtfast module to the 
number available from the operating system. If 
the operating system does not offer enough buffers 
to accommodate the number requested by the user, 
Prtfast limits the number of buffers required. 

Whenever the application program makes an 
output request, Prtfast loads the data passed in 
the CALL parameter into an available buffer. If 
the operating system cannot handle the output re¬ 
quest immediately, it establishes a loop between 
the channel queue and the problem program. 

This loop continues until an entry becomes avail¬ 
able or an interruption from a higher priority 


partition occurs. Prtfast 1 s task selection pre¬ 
vents the loop from being set up and causes con¬ 
trol to be passed to a lower priority partition 
that is ready to execute. 

Each time the user program receives control 
from Prtfast after an output request, the passed 
parameter is returned unchanged. 

Output . The output from Prtfast is the pro¬ 
gram output on printer, tape, or disc. 

SUPPORT 

Included in the package price are documenta¬ 
tion, maintenance, and updates. Prtfast is in¬ 
stalled by the user according to written instruc¬ 
tions from the supplier, and no training is nec¬ 
essary. Documentation of the system consists 
of an introductory descriptive brochure and a 
system reference manual. 
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UNIVERSAL SOFTWARE 

DOS ASAP 


GENERAL 

DOS ASAP (Automatic Spooling with Asynchro¬ 
nous Processing) is an automatic spooling system 
for the IBM 360. It operates asynchronously 
with problem programs and acts as an extension 
of the supervisor residing in upper core. 

The system runs on IBM 360/25 (DOS) and up 
with a minimum of 24K bytes of main core stor¬ 
age and requires a minimum 2K bytes of resident 
core for printer/punch support and 3K for print¬ 
er/punch-reader support. Core buffer space is 
user specified, but IK bytes is a recommended 
minimum. Minimum disc storage recommended 
is 10 cylinders of a 2314 or 30 cylinders of a 
2311 depending on the installation. Source lan¬ 
guage is BAL. 

Cost is $3, 500 for the full version, $2, 900 for 
the writer version, $2, 500 for the second user 
location, $1,500 for the third user location, and 
$1, 000 for each subsequent location. Immedi¬ 
ately available. 

PACKAGE DESCRIPTION 

Spooling is a technique that has been used for 
some time to decrease problem program execu¬ 
tion time by intercepting supervisor calls (SVC) 
for unit record devices, and placing the output 
data on a magnetic storage device. After the 
problem program runs to completion, the data is 
retrieved from storage and printed. Quite sim¬ 
ple? Yes. But also quite costly in both auxil¬ 
iary storage space, the amount of time required 
to ultimately print the data, and the overhead in¬ 
curred by having printers and punches sitting 
idle while the data is being spooled. In fact, con¬ 
ventional spooling is so time consuming, some 
packages using it fail to mention print times in 
performance data. 

To counter conventional spooling deficiencies, 
a number of spooling packages have recently 


emerged. These systems generally use the 
same techniques as conventional spooling to 
transfer to and from storage buffers but differ in 
the way they handle I/O commands and store rec¬ 
ords. Most of the newer systems either use 
their own supervisor or modify the host system 
supervisor to intercept SVCs for an output oper¬ 
ation. A SAP appends code to the host supervisor. 

The ASAP logic resides in high core and com¬ 
municates directly with the host supervisor by 
means of branch tables in order to analyze SVCO 
and I/O interrupts. It also uses its own I/O con¬ 
trol tables to identify files and devices to be sup¬ 
ported. ASAP offers an option that allows each 
spool disc file to be associated with as many 
spoolable devices (such as printers and punches) 
as desired, and devices may be interchanged 
within spool files at execution time. 

One of the prominent features of ASAP is its 
ability to output data in printed and punched form 
while the problem program is still being exe¬ 
cuted. This is possible because ASAP intercepts 
the host supervisor calls which control unit rec¬ 
ord entries to the channel scheduler. It also 
generates its own channel command words (CCW) 
and can link these to maximize data transfer. 

Upon examining the PUB at channel scheduler 
time, ASAP determines if the device is one under 
its control. If not, control is returned to the 
system supervisor for execution. 

Data bound for output is transferred to a buff¬ 
er storage area under control of the ASAP logic. 
The number and size of the buffers is specified 
by the user. Should all core buffers be full, the 
data overflows to disc. As each print line is 
stored in core, a switch is tested to determine 
whether the I/O device has already been started; 
thus the first line of data stored in the buffer can 
be transferred immediately to the unit record 
device assigned to that buffer, and each subse¬ 
quent line will be output as the I/O interrupts 
occur. 
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The number of core buffers available for stor¬ 
ing records associated with a spooled device can 
be as high as 20; buffer size is entirely up to the 
user. Each buffer is a fixed length block of vari¬ 
able length lines. Thus for best utilization of 
disc and core and also reduced seek times, one 
would be wise to choose a buffer size that con¬ 
siders both core available as well as efficient 
disc utilization. 

ASAP also offers a forms alignment routine 
which enables print carriage characteristics to 
be conveyed to the spool routine. As lines are 
spooled out, the theoretical position within a 
page is maintained allowing proper handling of 
forms overflow. The forms alignment routine 
permits the perpetual reprinting of one line of 
print, pausing to allow adjustment until the op¬ 
erator is satisfied with the alignment. A printer 
backspacing feature allows reprinting of a page 
in the event of a forms jam. 

The system also permits pseudo devices to be 
defined in the supervisor to simulate additional 
unit record devices which are not physically avail¬ 
able. These devices enable programs to function 
in partitions, and when a device becomes avail¬ 
able the output is spooled to it. 

ASAP is available in two versions: a writer 
system and a full system. The writer version 
spools any number of printers and punches (both 
real and imaginary); the full version has the 
same capabilities as the basic but supports card 
readers as well. All other system capabilities 
apply to both versions. ASAP also fully supports 
COS, CS/30, and CS/40 emulator programs. 

ASAP works equally well in a multiprogram¬ 
ming and nonmultiprogramming environment. It 
does not, however, require a multiprogramming 
supervisor or storage protect features. The 
users we spoke to were extremely enthusiastic 
about ASAP, and confirmed it did operate as ad¬ 
vertised and increased their throughput. Some 
mentioned a few bugs had occurred, but the ven¬ 
dor was quick to correct them. 

Input . Inputs to ASAP consist of data records 
loaded to buffer storage areas contained in core 
and/or on disc. 

Process and Output . During normal process¬ 
ing, routine data transfers cause the ASAP super¬ 
visor to place record data in designated core buff¬ 
ers. If buffer overflow can occur — which is usu¬ 
ally the case in large-volume output programs — 
this overflow must be stored on disc. ASAP of¬ 


fers an option that allows the user to specify a 
single spool file to be shared by all unit record 
devices or to allocate a spool file for each device. 

In all cases, the address of the physical de¬ 
vice to be used or the device address referenced 
by programs via logical unit assignments must be 
given. The advantage of having more than one de¬ 
vice sharing the same file is that as blocks are 
written to the file for various devices they will 
likely fall in the same cylinder, therefore reduc¬ 
ing seek time which would normally occur when 
more than one spool file is being utilized on the 
same physical disc unit. 

This method can, however, reduce the effi¬ 
ciency of disc space utilization should a low us¬ 
age device not be operational for some reason, 
thus causing its records to be temporarily irre¬ 
trievable. When this happens certain disc space 
beyond the unretrieved records may become un¬ 
available to the high use device until the other 
records are retrieved. 

FEES AND SUPPORT 

The purchase price of the package includes ob¬ 
ject code, documentation, updates, and a lifetime 
guarantee against source code bugs. 

Installation. The vendor will assist with the 
installing, but there are charges for this service 
on a fee plus per-diem basis. Most users, how¬ 
ever, should be able to install the system using 
the implementation procedures supplied by the 
vendor. 

Training . Can be provided by the vendor on 
the same fee schedule as installation. This 
should be unnecessary, for the user documenta¬ 
tion is fairly clear and the number of statements 
used by DOS ASAP is small. 

Documentation . Includes a systems program¬ 
mers guide, operators guide, object code, and a 
general information document. The systems pro¬ 
grammer s manual is short, to-the-point, and 
provides instructions on how to configure and in¬ 
stall the ASAP system. The operators guide is 
also concise and contains commands necessary 
to operate the system. The general information 
document is sales oriented and stresses the fea¬ 
tures and operational advantages of ASAP. 

Maintenance . The system is fully warranted 
against bugs for the life of the package. Enhance¬ 
ments are also provided free of charge. 
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UNIVERSITY COMPUTING 

UCC Two 


GENERAL 

UCC Two (formerly called DUO 360/370) is a 
systems program from the Utility Division of 
University Computing, which allows DOS problem 
programs to run in an OS environment, thus 
availing themselves of OS facilities. No repro¬ 
gramming is necessary. UCC Two operates on 
the IBM System/360 or 370 under PCP, OS/MFT, 
OS/MVT, or OS/VS1. Total storage requirement 
is 25K bytes, of which 6 to 16K bytes per parti¬ 
tion must be core resident. 

The 2 comprise a 1,200-byte appendage (called 
the DOS SVC filter) to the DOS nucleus and about 
40 assembly-language programs. It permits DOS 
object programs to run in an OS partition — and 
use facilities — by trapping DOS supervisor 
calls (SVCs). 

DESCRIPTION 

"A DOS to OS conversion! ... deliver me!" 
This refrain (along with a few unprintable direc¬ 
tives to the suggestor) has become a conditioned 
response from those who have suffered the winters 
of crippling delays while awaiting the promised 
kiss of springtime — viz., OS facilities in a 
DOS shop. 

Seriously, a DOS to OS conversion is a pain 
mainly because most installations can ! t afford 
delays while production runs are being converted 
or rewritten. Consequently, those shops choos¬ 
ing to go the conversion route must allocate 
portions of their shifts to run the old system as 
backup while conversion is taking place. 

For those sufficiently far enough along in 
their conversion to benefit from simultaneous 
operation of DOS and OS, 2 options exist: the 
IBM-supplied DOS emulator and independently 
marketed packages like UCC T s Two. 

Basically, the Two is designed to allow DOS 
object programs to run in an OS region or parti¬ 
tion, and to avail themselves of OS facilities. 

DOS jobs, for example, may use the OS data 
management facilities (including spooling); all 
jobs can be read through 1 job stream and pro¬ 
cessed via 1 queue; up to 15 programs can run 
concurrently. In addition, DOS and OS jobs can 
run at the same time and processing modes can 
be switched between OS and DOS within a single 
job step. 

The Two, however, does impose a few re¬ 
strictions: (1) It does not support nonrelocatable 
DOS programs other than LUBs and PUBs; (2) 
BTAM and QTAM are not supported; (3) many 


time-dependent programs are not supported; and 
(4) DOS ISAM data sets cannot be read or created 
because OS ISAM data management facilities are 
used. 

Input. The Two accepts only DOS object pro¬ 
grams with OS job control. DOS job control 
must be converted to OS JCL, which is both a 
help and a hindrance. It T s a help because you 
have to be very aware of OS JCL before you even 
use the Two (you don T t with IBM’s emulator). 

Data files used by the DOS programs do not 
have to be converted, except for ISAM and split 
cylinder data sets. The former have to be re¬ 
created under QISAM after being dumped by DOS. 
The latter have to be recopied. If you’re running 
DOS Release 25 or later, the Two can use the 
same ISAM dumped file. 

Process. The Two appends code to the OS 
nucleus at SYSGEN time. It therefore ’’modifies” 
the operating system only for as long as that 
version of OS is being used. This approach is 
consistent with that employed by many of the 
’’add-on” packages on the market, and neatly 
sidesteps customer reluctance to use a package 
which modifies the operating system permanently. 

The appended code traps DOS SVCs, converts 
the service requests to suitable OS form, and 
interfaces these requests to OS facilities for 
action. Since all service requests are converted 
directly by the Two, no modifications to the DOS 
programs are necessary. 

Evaluation 

Since the Two is considered an emulator, 
you’ll probably have to evaluate it against the 
IBM OS/DOS emulator, mainly because that 
package is offered free to all System/370 Model 
135 through 158 users — except those with the 
Model 155. The IBM offering is not available to 
System/360 users, so if you like your machine 
but want OS, you’ll have to go to a package like 
the Two. 

IBM Emulator Versus the Two. First, we’ll 
deal with the OS/DOS emulator. System/370 
users receive a mixed blessing in the DOS emu¬ 
lator. On the negative side is the system degra¬ 
dation caused by facilities and resources which 
must be dedicated to DOS. These include fairly 
large amounts of core: 22K plus DOS control 
program (16 to 28K) and partition(s) for OS/MFT; 
28K plus DOS CP and partition(s) for OS/MVT. 
Unless you’re running HASP, the DOS programs 
must have discs (except spooled data sets) dedi¬ 
cated. You can run 3 DOS partitions, but by the 
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time you’re through allocating core (unless 
you T re running under VS), you might just as well 
have dedicated your machine, especially since 
the DOS emulator does not provide storage 
protection. 

If you want both DOS and OS programs to 
access an ISAM data file, you T ll need 2 data 
files — 1 for each system — if only the emu¬ 
lator is used. If you want to print spooled out¬ 
put from DOS you must wait until the entire 
DOS job stream has finished executing, unless 
you T re running under HASP. Last, but cer¬ 
tainly not least, you must use both DOS and OS 
job control cards for each emulator rim. 

On the positive side, the DOS emulator sup¬ 
ports BTAM as well as various DOS source lan¬ 
guage compilers, private libraries, sorts, util¬ 
ities, and MICR. Since OS runs the DOS emula¬ 
tor as a job step, OS program steps can be 
mixed in with the DOS executions, and since 
successive DOS program calls are permitted 
within a single DOS emulator step, DOS jobs can 
be read through one job stream. 

Another plus is that DOS control cards needn’t 
be touched; in many cases only 3 or 4 OS JCL 
cards (including delimiters) are required to 
invoke the DOS emulator procedure. 

The UCC Two offers many of the good points 
of the IBM DOS emulator while avoiding many of 
its limiting features. 

The Two requires from one sixth to one half 
the main storage needed by the emulator and 
makes OS facilities available, including more 
than 3 partitions, with storage protection. In 
fact, unlike the emulator, it provides DOS pro¬ 
grams with an OS environment instead of re¬ 
creating a DOS environment. This is especially 
good for shops that do not wish to convert cer¬ 
tain fixed production rims, that want to stay 
within the System/360 line or soften their con¬ 
version efforts toward the end of the conversion 
process. 


The Two does not support 1400 emulation 
(neither does the emulator) or some time-depen¬ 
dent programs (the interval timer is treated as 
elapsed time). It places restrictions on such 
events as multitasking, checkpoint/re start, and 
so on, and does not support BTAM, some DOS 
source language compilers, private libraries, 
utilities, etc. MICR is acceptable. 

Tape data sets can also be a problem because 
of tape marks (or lack thereof) and the resulting 
effect of multifile tapes; because of tape label 
formats; because of duplicate volume serial 
numbers; and because DOS allows its labels to 
contain special characters, including blanks in 
the first position (OS does not). 

FEES AND SUPPORT 

The Two is available on System/360 Models 
40, 50, and 65 and is available on a monthly lease 
for $800, $1,200, and $1,600, respectively; a 
6-month lease is also offered for the same 
machines and is billed at $720, $1,080, and 
$1,440, respectively. Purchase prices, respec¬ 
tively, are $7,200, $10,800, and $14,400. 

These prices also apply to System/370 Models 
145, 155, and 165. If you’re planning a third- 
party external application, you pay one third 
more to purchase and 75% more to lease. Month¬ 
ly leases can be canceled on 30 days’ notice. 

Six-month leases have a 25% purchase option. 

Maintenance for all leases is free. Purchased 
systems come with 1 year’s free maintenance, 
with an optional contract thereafter. Discounts 
are available for multiple CPU licenses. 

Interestingly enough, the purchase price of 
the Two for the 155 ($10,800) is exactly the price 
of the IBM DOS emulator for the same machine. 

HEADQUARTERS 

University Computing Company 

P.O. Box 47911 

Dallas, TX 75247 
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Computer Scheduling and Control System 


GENERAL 

The Computer Scheduling and Control Sys¬ 
tem — or (CS) 2 as Value calls it — is a set of 
batch-oriented programs aimed at getting the 
most out of the system by providing information 
that will allow users to intelligently schedule 
jobs. All programs are written in Cobol and run 
on the System/360 or 370 (DOS, OS, and VS) or 
the Univac Series 70 (TDOS or DOS). Hardware 
requirements are 90K bytes, 1 magnetic tape 
drive, approximately 50 cylinders of 2319 disc, 
a card reader, and a line printer. 

(CS) 2 is available under a perpetual license 
with free first-year maintenance; thereafter, an 
annual maintenance/enhancement contract is 
available. The individual programs and their 
license fees are as follows: 

• Job Accounting (System I) — $4, 000. 

• Job Costing (System II) — $2,000. 

• Enhanced Job Costing — $3,500. 

• Job Accounting & Billing — $7, 500. 

• Single Machine Schedule (System III). 

(1) DOS (or DOS/VS) - $7,000. 

(2) OS/MFT (or VS/l) - $10,000. 

(3) OS/MVT (or VS/2) - $12,000. 

• Multiple Machine Scheduler. 

(1) DOS (or DOS/VS) - $20,000. 

(2) OS (or VS) — $25,000. 

• Tape Library Monitor. 

(1) DOS (or DOS/VS) — $4,000. 

(2) OS (or VS) - $6,000. 

DESCRIPTION 

The axiom that, "the more intelligently jobs 
are scheduled, the greater the throughput and the 
higher the resource utilization, " is well known to 
every DP manager. But implementing it is an¬ 
other matter! The man would literally have to 
match priorities with job profiles to attain an 
optimal schedule — an unbelievably difficult task. 

(CS) 2 in itself provides no instant solution to 
this problem; it does, however, provide sug¬ 


gested schedules plus data to allow users to 
make intelligent decisions. 

(CS) 2 is an evolutionary product; its lineage 
can be traced to Value’s single machine schedule 
package first installed in 1969. This scheduler 
is retained in (CS) 2 under the name System III. 
The old System III did have a problem, however; 
viz., although its input data was derived from 
the computer system’s time accounting routines, 
it had to be prepared manually. Value automated 
this phase in 1970 with the introduction of System I. 

During the following 3 years. Value enhanced 
Systems I and II, added a multiple machine 
scheduler, a billing system, and a tape library 
monitor. The result is the current version of 
(CS) 2 . 

Processing Components 

Although the principal feature of (CS) 2 is un¬ 
doubtedly its scheduling capability (System III), 
the capabilities of the other components — both 
those that interact with System III and the com¬ 
ponents that stand alone — are certainly worth 
noting. 

System I. This component interfaces with the 
time accounting or log data captured by the com¬ 
puter system. It is run as a batch program and 
establishes a workload control file, which con¬ 
tains information useful for scheduling (namely, 
computer configurations, applications). Since 
this information is based upon historical run 
profiles, the component can be altered to reflect 
nonstandard workload projections. 

In addition to the Workload Control File, Sys¬ 
tem I also produces 2 classes of reports: daily 
performance reports showing shift summaries, 
multiprogramming graphs, details on runs, idle 
time, and equipment malfunction; and the 
monthly/quarterly/year-to-date reports showing 
device usage and malfunctions, device exceptions, 
rerun summaries, major and minor accounting 
statistics, major application graph, and system 
usage. 

System II. System II is basically a job cost¬ 
ing module and is usually run at the end of the 
month with System I. With System II, jobs can 
be billed according to the resources utilized, 
viz., CPU time, main storage used, number of 
cards read and lines printed, and EXCPs by class 
of device (I/O device utilization). For virtual 
memory systems, this module also records pag¬ 
ing activity. 

Besides the billing reports. System II also 
produces a run utilization report, an application 
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utilization report, a cost feedback report, and 
a major application cost graph. 

The run utilization report presents a cumu¬ 
lative picture of job activity during the preceding 
month, broken down by job ID, resource utiliza¬ 
tion, and job charges. The application utilization 
report provides up to 3 levels of accounting for 
each major application system by detailer job, 
minor application subsystem, and overall ap¬ 
plication system. 

The feedback report contains a breakdown of 
charges distributed to individual resources. This 
report can be used to adjust billing rates and/or 
the fundamental structure of the charging algorithm. 

The enhanced version of System II is called 
Comput-A-Charge. It can also be used in con¬ 
junction with System I and provides the following 
features: daily costing in addition to MTD and 
YTD summaries; different shift/priority billing; 
more detailed I/O device billing, including par¬ 
tial disc pack utilization, etc.; and Time Sharing 
Option (TSO) accounting, including connect time, 
line in/out counts, and concurrent user graphs. 

In addition, System II also produces a paging 
usage graph showing the paging rate as a function 
of time, program frequency counts for up to 50 
program names, and historical profiles showing 
system utilization data by application over a 12- 
month period. 

System III. The principal module of (CS) 2 is 
System III, the job scheduler. Using the data 
contained in the Workload Control File (produced 
by System I), System III applies a series of 
complex algorithms to produce a coordinated 
schedule that allows an appropriate mix of I/O 
and CPU-bound jobs. This schedule also shows 
which jobs should be run in which partition/re- 
gion and at what time. 

Since System III draws its input from the 
workload control file, it can be used to "fine 
tune" the schedule to meet changing processing 
demands. 

Three major subsystems comprise System III, 
namely, the SCHED program, the MAINT program, 
and a long-range scheduling program called 
SCHED 31. The SCHED program takes user- 
specified scheduling parameters and produces the 
schedule with beginning and end times for each 
job, plus individual-program main memory 
locations. 

This program produces a load list with all 
runs identified, and a status report listing all 
jobs along with run model data contained in the 
workload control file. These values can be tem¬ 


porarily changed for the current scheduling run. 
Also produced is a schedule showing which jobs 
should be run in a certain partition/region and 
at what time. The MAINT program permits the 
user to add, modify, or delete program profiles 
in the workload control file. It produces a con¬ 
firmation list of changes required in the data 
base by the user, and an actual versus sched¬ 
uled report to measure the accuracy of the values 
used in the scheduling algorithm. 

SCHED 31 forecasts up to a month’s upcoming 
workload, but not to the same level of detail as 
the daily (or shift) scheduling run. This sched¬ 
uler also produces a summary report that shows 
projected total run time, average main memory 
usage, total number of runs, and time and per¬ 
centage of utilization for each type of peripheral 
device. 

Multiple Machine Scheduler. The most com¬ 
plex — and expensive — component in (CS) 2 is 
the multiple machine scheduler. Capable of 
producing a composite workload for up to 15 sys¬ 
tems, each job is designated to have a preferred 
configuration and up to 4 alternate systems. 

Tape Library Monitor. The tape library mon¬ 
itor is an independent system that handles the 
administrative functions of maintaining the li¬ 
brary, including inventory reports and other 
optimal record keeping. The library’s inputs 
can come from the workload control file, the 
system’s accounting routines, or it can be en¬ 
tered manually. 

Four modules make up the library monitor: 
the tape library maintenance program, the daily 
tape feedback program, the daily tape procedure 
program, and the tape report program. The 
maintenance program creates, modifies, or 
deletes tape library information in the workload 
control file. The feedback program accepts 
current status information on newly created or 
deleted tape volumes (by serial number). The 
procedure program interfaces with System III, 
and produces a setup list in proper time se¬ 
quence for the scheduled runs. If System III is 
not being employed, the list appears in a job 
name sequence. The report program generates 
a number of administrative reports on demand. 

FEES AND SUPPORT 

The license fee covers maintenance, en¬ 
hancements, and support for the first year only . 
Thereafter, maintenance/enhancements are 
available on a set fee basis. 

HEADQUARTERS 

Value Computing, Inc. 

496 N. ICings Highway 

Cherry Hill, NJ 08034 
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WEBSTER COMPUTER 

DOS Selfrelo 


GENERAL 

DOS Selfrelo program makes DOS object mod¬ 
ules relocatable for execution in any DOS parti¬ 
tion. The package operates on an IBM System/ 
360 Model 25 and up or System/370 under DOS. 

It is linked to the DOS supervisor and requires 
480 additional bytes. DOS Selfrelo is written in 
BAL. 

Purchase price for the first installation is 
$3,000; subsequent installations cost $1,000 each. 
Leases can be negotiated. The package is avail¬ 
able for immediate delivery. 

DOS Selfrelo was first installed in 1970 and is 
operational in approximately 130 installations. 

DESCRIPTION 

The DOS Selfrelo package enables an object 
module to be cataloged once in the core image li¬ 
brary and then executed in any of the three DOS 
partitions. It thus eliminates the need to recata¬ 
log DOS object modules when the supervisor size 
is increased or a partition size is changed. The 
package accepts object modules produced by 
Cobol, ALC, PL/l, Fortran, or RPG compilers, 
as well as operating system components and sys¬ 
tem utility programs. 

DOS Selfrelo operates differently from most 
relocation packages. Rather than add a control 
section to the beginning of the object module, it 
creates a file containing a 182-byte record for 
each program phase containing relocatable ad¬ 
dresses. Subsequently, this record is read each 
time the program phase is executed. 

An IBM DOS supervisor macro is replaced at 
installation time by a Selfrelo macro which dy¬ 
namically resolves all relocatable addresses each 
time the stored object module is executed. This 


modification adds 480 bytes to the supervisor, 
but no core is added to any user program. 

Using relocation packages like DOS Selfrelo 
results in conservation of storage, reduced oper¬ 
ations time and expense, improved job scheduling 
through partition independence, and increased 
multiprogramming flexibility. 

Users reported a few areas in which problems 
arose. Some with ISAM and BTAM files found 
Selfrelo was not relocating address constants 
properly. These, however, seem to be isolated 
cases since not all ISAM and BTAM users had 
problems. Generally, users are pleased with the 
ease of use and benefits derived from using DOS 
Selfrelo, though they agreed that package updates 
are not always available on time. This could be 
attributable, at least in part, to the considerable 
number of installations using the package. That 
DOS Selfrelo users should report this situation is 
unusual because users of Webster’s other pack¬ 
ages have never offered similar comments. 

SUPPORT 

DOS Selfrelo is distributed via tape or cards 
in the form of a job stream including the appro¬ 
priate JCL for cataloging each object module. 
Along with the Selfrelo program, the vendor sup¬ 
plies code to establish the relocation data file and 
substitute the DOS Selfrelo supervisor macro for 
IBM’s (which is saved). 

Training of user personnel is unnecessary. 

Documentation includes a brief abstract and a 
more detailed guide describing implementation, 
logic, and sample jobs. 

Maintenance is supplied at no additional charge. 
Updates are supplied automatically whenever IBM 
releases a new version of DOS. 
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WHITLOW COMPUTER SYSTEMS 

SyncSort 


GENERAL. 

SyncSort is a sorting system which uses its 
own timing program to determine the optimum 
environment in which to perform the sort. It is 
functionally compatible with IBM T s sort programs 
SM-023 and SMI. 

The sorting system runs on an IBM System/ 
360 Model 50 and up and on the System/370 Model 
155 and up under OS. SyncSim, an associated 
timing program, requires 50K bytes of core un¬ 
der MFT, 60K bytes under MVT. SyncSort 
needs 10% more random access storage than the 
number of bytes to be sorted and a minimum of 
32K bytes of memory. At least one random ac¬ 
cess device (any manufacturer’s) is necessary 
for the sorting operation. Written in BAL and 
Fortran, the package is available for imme¬ 
diate delivery. 

The SyncSort system is licensed on a 1-year 
or 3-year basis, per computer. Table 1 sum¬ 
marizes the license options. 


Table 1. Whitlow — SyncSort: Fee Schedule 


NO. OF 

LICENSE ($) 

COMPUTERS 

1 Year 


3 Year 

1 

3,000 

6,200 

1-9 

2,700 

5,500 

10 or more 

2,500 

5, 000 


Note: 

There will be a release charge of $50 added to 
the first invoice for each computer program 
ordered. Any future improvements in the pro¬ 
gram are available upon request and will be de¬ 
livered in tape form for $50. 


SyncSort is licensed for a particular computer 
and is not contractually eligible for transfer be¬ 
tween computers unless the prior computer is 
discontinued. 

SyncSort was introduced in December 1971, 
and has been expanded by new releases 4 times 
since its introduction. New releases are made 
available to current users at a charge of $50. 
Currently, it is operational in 60 installations on 
about 100 computers. 

Founded in 1968, Whitlow Computer Systems 
develops proprietary software and provides con¬ 
sultation to the planning functions of corporate 
EDP staffs. 


DESCRIPTION 

Operation efficiency is the ultimate goal of 
every computer installation, but it may be de¬ 
fined differently by different individuals. Sync¬ 
Sort allows 4 interpretations of efficiency: min¬ 
imum throughput time, minimum CPU time, 
minimum I/O time, or minimum number of I/O 
accesses. Once efficiency is defined to SyncSort 
(through a default value or parameter), SyncSort 
executes by using the allocated resources to 
achieve the goal. How well this objective is ac¬ 
complished depends on the allocated resources. 

The effect of varying the resources can best 
be determined by using SyncSim, a timing pro¬ 
gram included in the SyncSort package. Based 
on 15 parameters that describe a particular 
configuration, it simulates the execution of Sync¬ 
Sort on this configuration. SyncSim then prints 
out, among other variables, the throughput time, 
CPU time, I/O time, and number of I/O accesses 
which would result in a stand-alone environment. 
Varying the parameters enables a user to deter¬ 
mine how a change in the environment would ef¬ 
fect efficiency. 

SyncSort runs as a user program, and oper¬ 
ates with any manufacturer’s random access 
storage device (including the 3330). Although ef¬ 
ficient when only one device is used, perfor¬ 
mance naturally improves as more devices are 
made available. Sort performance is also im¬ 
proved with a positive or negative bias in the 
data to be sorted. (This is significant since most 
sort packages penalize for a negative bias in the 
data.) Variable and fixed length records can be 
sorted. 

SyncSort also offers a merge capability and a 
user exit availability compatible with IBM’s 
SM-023 and SMI. 

Input. Input to SyncSim is one or more data 
cards each of which describes a possible config¬ 
uration on which SyncSort will operate. The data 
card specifies: CPU model, operating system 
version, type of efficiency desired, core size, 
input device, output device, record length, in¬ 
put and output blocking factors, number of rec¬ 
ords to be sorted, channel distribution, working 
device, number of working tracks, and amount of 
bias specified as a number. 

SyncSort requires that the user enter the same 
sort parameters as those required by SMI or 
SM-023. The parameters include: amount of 
core available; method for handling messages 
control listing of output; amount of bias (optional); 
devices to be used for input, output, and work; 
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and the type of efficiency desired. Normally, 
these parameters are specified by the user when 
the package is ordered, and they become default 
values if no overriding value is specified at ex¬ 
ecution time. 

Process. SyncSim validates its data cards. 
Upon error detection it prints an associated er¬ 
ror message followed by a list of the card errors. 
Processing continues with the next data card. A 
valid card causes simulation of the sort operation 
on the specified configuration. 

SyncSort validates control cards for form and 
content. A critical error results in program 
termination. 

To assure the validity of a sort in process, 
approximately 100 different checks are itera¬ 
tively applied and, in addition, an internal trace 
of critical paths is in continual operation. An 
input as well as an output sequence check is also 
made to ensure that string sequence has been 
maintained. If any check fails, SyncSort termi¬ 
nates. When a sort is terminated, a snap dump 
is taken to help determine the nature of the 
problem. 

Depending on the type of efficiency desired, 
SyncSort will modify its logic during execution 
to achieve it. For example, if reduced I/O time 
is the goal, SyncSort will evaluate possible solu¬ 
tions in terms of the associated I/O time 
expected. 

Output. SyncSim produces a listing for each 
sort simulated, which provides: the number of 
tracks used by a sort, the minimum number of 


tracks needed by the sort, the maximum number 
of records which could be sorted with the avail¬ 
able tracks, the total number of EXCPs that 
would have been issued during the sort, the total 
amount of I/O, CPU, throughput, and I/O times 
in seconds. 

Besides the sorted file, SyncSort, produces 
information messages, and an optional listing 
of the input control cards. 

Evaluation. Although SyncSort appears to be 
conceptually good — and most packages do look 
good on paper — we were unable to verify its 
effectiveness because the vendor would not sup¬ 
ply a list of users. 

SUPPORT 

Documentation and maintenance are included 
in the license price of the package. 

The user receives SyncSort on tape along with 
2 user manuals. He must install the package and 
return the tape to the vendor. 

Whitlow will provide service to correct any 
programming errors in SyncSort and to maintain 
its compatibility with changes to the operating 
system on which it is running. 

Training in SyncSort operation is unnecessary. 

HEADQUARTERS 

Whitlow Computer Systems Inc. 

1029 Teaneck Road 

Teaneck, NJ 07666 
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INDEX AND SUPPLIERS 


System 

Amigos 

Anyplace II 

Auto-Cat 

Computer Scheduling & Control 

Deep/360 

DOS/ 360 

DOS ASAP 

DOS Selfrelo 

DOS/VS 

EDOS 

Fast/Dump/ Restore 

GECOS III 6000 Series 
Grasp 

Jasper 


Supplier 

System 

Supplier 

Comress 

2 Research Ct 

Rockville MD 20850 
(301) 948-8000 

Master 

Control Data Corp 

8100 S 34th St 

Minneapolis MN 55440 
(612) 853-8100 

Marcus Powell Associates 

2694 Doidge Ave 

Pinole CA 94564 
(415) 758-6080 

MCP V 

Burroughs Corp 

World Headquarters 

Burroughs PI 

Detroit MI 48232 
(313) 972-7000 

Mnemotech Computer Systems Inc 

55 Liberty St 

New York NY 10005 
(212) 267-8762 

Value Computing Inc 

OS/7 

Sperry Rand Corp 

Uni vac Div 

PO Box 500 

Blue Bell PA 19422 
(215) 646-9000 

383 Kings Hwy North 

Cherry Hill NJ 08034 

OS/360 

IBM (see DOS/360) 

(609) 667-8770 

Macro Services Corp 

151 Tremont St 

Boston MA 02111 

OS/2000 

Honeywell Information Systems Inc 
60 Walnut St 

Wellesley Hills MA 02181 
(617) 237-4100 

(617) 423-6250 

IBM 

OS/VS 1 & 2 

IBM (see DOS/360) 

Data Processing Div 

112 E Post Rd 

White Plains NY 10601 
(914) 949-1900 

Pi Sort 2 

Applied Data Research Inc 

Route 206 Center 

Princeton NJ 08540 
(609) 921-8550 

Universal Software Inc 

12 Horseshoe Dr 

Danbury CT 06810 
(203) 743-1381 

Prtfast 

Software Techniques 

PO Box 55 

Old Bethpage NY 11804 
(516) 643-3013 

Webster Computer Corp 

One Padanaram Rd 

Danbury CT 06810 
(203) 744-6500 

Reloc 

Computer Guidance Associates 

8221 Third St 

Downey CA 90241 
(213) 773-9556 

IBM (see DOS/360) 

The Computer Software Co 

7th and Franklin Sts 

Relo/360 

Associated Computing Services Inc 
12011 San Vicente Blvd 

Los Angeles CA 90049 
(213) 476-6515 

Richmond VA 23219 

(703) 648-5823 

Scope 

Control Data Corp (see Master) 


Innovation Data Processing 

Sprint 

Jason Data Services 

925 Clifton Ave 


903 E North St 

Clifton NJ 07013 


Mateca CA 95336 

(201) 777-1940 


(209) 823-2980 

HIS (see OS/2000) 

SyncSort 

Whitlow Computer Systems Inc 
1029 Teaneck Rd 

Software Design Inc 


Teaneck NJ 07666 

872 Hinckley Rd 


(201) 837-3010 

Burlingame CA 94010 

(415) 697-3660 

UCC Two 

University Computing Co 

800 UCC Tower Box 47911 

Datachron Corp 


Dallas TX 75247 

174 Fifth Ave 


(214) 637-5010 

New York NY 10010 

(212) 675-5333 

1100 Series Exec 8 

Univac (see OS/7) 
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A complete data processing library-contained 
in two, easy-to-work-with volumes! 


Every month you receive an infusion 
of new knowledge — each Portfolio is 
an iii-depth “intelligence capsule”on 
a specific DP problem. 

AUERBACH’S DATA PROCESSING MANUAL 
is modern. Fast. Practical. A streamlined system 
of specialized Portfolios divides and sub-divides 
every aspect of DP management and groups each 
subject into logical categories of specific problem 
areas. To find an answer, all you do is select the 
Portfolio relating to your specific problem. Each 
one provides just as much or as little information 
as necessary to help you arrive quickly, safely 

SPECIALIZED 
INFORMATION... 
TIME-SAVING CHARTS. 
CHECKLISTS, SURVEYS, 
WORKSHEETS,FORMS... 
CONTINUOUS, 
YEAR-ROUND 
COVERAGE... 

YES! . . . Send me the AUERBACH Data 
Processing Manual on 30 days’ approval 
and reserve a subscription for me. 


at an effective solution. Coverage is sharp and 
to-the-point, tightly-written in clear, everyday 
language. Best of all, every Portfolio is a complete 
and definitive analysis on its subject-thus you 
have just one place to look for your answer. 

What you get, in effect, is a complete data processing 
library in two volumes — a year-round service 
delivering a constant stream of new Portfolios that 
continually add to your knowledge. And because each 
Portfolio is a self-contained unit, filing them into your 
volumes each month take just a matter of seconds. 
Individual Portfolios can also be withdrawn and used 
separately without disturbing the entire service. 

Use the AUERBACH Data Processing 
Manual for 30 days at our expense . . . 

. . . and if you decide to subscribe — 
receive the complete expanded service* 
at the current low rate! 

♦Includes: 

Time-Saving Aids — charts, tables, checklists, diagrams, 
model forms and agreements. More than 50 New 
Portfolios this year — up-to-the-minute coverage ana¬ 
lyzing specific DP management problems 

Major New Innovations — EDP Surveys, Case Histor¬ 
ies, (< Ask AUERBACH” 

Extra Specialized Coverage — specific applications by 
type of company, geographical location, etc. 

Two Volumes — expanded coverage converts Manual 
to 2-volume service 


“The AUERBACH Data Processing Manual is 
excellent. . . . It’s very well done. . . . personally 
I’m learning a great deal. . . . also using the indi¬ 
vidual folios for in-house training. . . . it’s been 
very useful for this purpose.” 

William C. Chapman, DP Manager 
Georgia Hospitals Computer Group 


Please ship on 30-day approval the one-volume Data Processing Manual con¬ 
taining more than 50 Portfolios. If at the end of 30 days I decide not to sub¬ 
scribe I will return the volume and owe nothing. If I decide to continue the 
service, you will activate my one-year subscription and begin sending new 
Portfolios every month for the next 12. I understand this entitles me to 
receive the complete expanded service including all new Portfolios, new 
features, and a second volume when issued in March. For all this you will 
invoice my company at the current rate of only $150 (after March 1, $175.00), 
plus any local sales tax. 


“I find the Manual very informative in keeping me 
up on the latest trends. You have gotten down to 
some of the important nitty gritty that is often 
overlooked.” 


NAME AND TITLE 


COMPANY AND DIVISION 


ADDRESS 


T. M. Conroy, Vice President 
Information Systems 
Magic Marker Corp. 

Cherry Hill, New Jersey 

ACTR BRC-1 (1/74) 
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AUERBACH 
Data Processing 

Manual 

... “a monument on data 

processing management... 
an excellent educational tool 
and operational guideline for the 
System/3 DP manager.” 

Group/3 Journal 

Now, for the first time in one place, you can find 
specialized information for the DP manager, 
plus a wealth of time-saving “firsts” - brought 
to you in a clear, usable portfolio format. Every 
facet of data processing management - from 
training personnel to formatting finished reports 
- is organized, summarized, interpreted and 
evaluated expressly for you, the man on the 
firing line. 

You benefit from the combined experience of 
some of America’s most respected data process¬ 
ing authorities - specialists in every area of DP 
management who know the kinds of pressures 
you face every day ... in your own department, 
within the company, and from outside sources. 

Here, too, are the checklists and forms you need 
to insure covering all bases on scores of DP 
questions - regardless of how complex or out-of- 
the-ordinary. Many of these special aids have 
never been offered in any published data process¬ 
ing service. 

In short, when you encounter problems in your 
everyday operation, the new AUERBACH DATA 
PROCESSING MANUAL helps you minimize 
the impact and maximize efficiency by advising 
you what to do, when to do it, and exactly how 
to do it. 


Suddenly a whole new 
generation in data processing 
management guidance! 

A complete 
two-volume service 
designed specifically 
for the DP Manager 
of the seventies. 

Revealing EDP Surveys ... Detailed 
Case Histories ... A Unique User’s 
Forum-3 Unprecedented New Fea¬ 
tures that enable you to receive 
direct intelligence from every sec¬ 
tor of the data processing com¬ 
munity. 

Up to now, there has never been 
a really simple, effective way for 
DP managers to learn how other 
companies and managers are han¬ 
dling problems common to all. 

Now the Data Processing Manual 
is adding three uniquely different 
ways to help you make these im¬ 
portant comparisons. Brought to 
you in the same fast-moving Port¬ 
folio format as the rest of the 
Manual, it represents one of the 
most ambitious efforts ever under¬ 
taken in a DP service. It is also an¬ 
other example of how the Manual 
continually strives to bring to the 
DP Manager the most professional 
and personalized guidance available. 
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